>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.