Hi Craig,

Thanks for the reply. Isn't there a performance hit when using ADO with native VFP? I've played around a bit with ADO, based on Jim Booth's article and Markus Egger's discussion in his new book, but I must be missing something - I don't really see how it offers an advantage over ODBC/SQL if you're using external data. It seems less "databasey" to me. This is probably my naivite, but to me, it doesn't get much easier than ODBC combined with SQL, and I can easily bind my results to grids (which I don't use often, but still, the need is there). Perhaps I haven't yet experienced a difficult ODBC connection that is looming out there somewhere.

I've been following some of the threads about the new technologies and being left behind, and I'm not sure I'm sold on it. Contrary to some prevailing thoughts, I believe that it makes more sense to learn what you need to learn when you need to learn it, so you can focus your energies on being really good at the things you do know. It's just a matter of opinion. There's a fine line I like to tread between using cutting edge technology, and falling behind.

I do see your point about putting the non-UI tiers on an application server. I agree, and I've made that jump, but using a browser interface with WWWeb Connect running on the server rather than a VFP front end. Fortunately, my clients have been sold on this model. There are some drawbacks, but I think there are even more advantages. It's hard to argue against a platform independent client, especially one that's not linked to a particular machine.

Anyway - thanks again for the feedback. I found your n-Tier lecture extremely valuable and well presented. I learned a lot. Thanks.


>>After reading the transcript of Craig Berntson's n-Tier lecture last Wednesday (which was very informative and useful), I have a number of philosophical questions about n-tier design, and I was hoping some of you had some experience or ideas that could guide me and others like me in n-tier development.
>>
>>1) Messaging between tiers - This is my biggest issue. How do I communicate data changes between my interface tier and my business logic tier? I've played around with a number of ideas, like binding UI controls directly to biz tier properties. That doesn't feel quite right - it assumes to much interdependence between the UI and the business tier.
>
>Use ADO and bind the controls to the ADO recordset. You can't use the VFP grid for this, but you can use the MSDataGrid.
>
>>
>>I've also played with a SETVAL method in the business tier, so that every time there's a change in the UI, it calls this SETVAL method and tells oBiz of the change. This combined with a GETVAL method to retrieve the values of other properties in oBiz works pretty well, but it comes with it's own set of problems.
>
>You really should do it this way. The data is held in the ADO recordset. When you click the Save button, the RS is sent off to the Biz.Validate(). If the data is valid, it calls Biz.Save(), which calls the appropriate methods in the data services. If the validation fails, the appropriate error message is returned for display in the UI.
>
>>
>>And finally, what about populating grids in the UI? Sometimes a user might change a value, which affects a bunch of values in the grid. Assuming oBiz handles the logic, how does one best handle the changes to the cursor or table which populates the grid? So far, I've been passing datasessionid's to the biz object so it can update the cursor in the appropriate form, but something feels a little off about this.
>
>You can walk through the RS and save any needed changes.
>
>>
>>2) There was some discussion in Craig's lecture about what the middle tier should be. I think COM was the consensus. But Mike Helland asked a great question - why? Why do people think it should be that way? What's wrong with a separate class library that's just your business tier, and compiling them all into one app? In fact, especially if all the data is VFP, I can't see why one wouldn't do it this way. All my apps work this way, and frankly, it works great. I have no interest in using many of the MS tools available to me (i.e. MTS, ADO, etc.), because for me, they change RAD to SAD (Slow Application Development).
>
>Not if you design your framework correctly. Several of the recent threads have said that if you're not looking...and working with these newer technologies you're going to get left behind. I agree with this.
>
>As for Mike's suggestion, when you change the Biz rules, you still have to compile the application, thus causing the compiled code to change in the UI. You still have to redistribute the UI. Lots of value is added to n-tier by using COM and installing biz and data services on an application server.
>
>>
>>3) Finally, I'm sure there must be some books/articles which generically discuss n-Tier design, and the associated patterns/anti-patterns. I've found a few patterns books, but they're so *$^#&$ dry that I have trouble getting through them. Anyone have any advice on where to find good discussions of this topic.
>
>There aren't many out there. "Effective Techniques" touches on it a bit, as does Markus's book.
>
>>
>>Thanks in advance for your thoughts.