Hi John,

Thanks to you and others, for the wealth of practical advice flowing in this thread.

>The middle tier can be made up of many layers. Notice I never called it my business tier challenge. So, in this case, you have created a component for the UI-Services Tier, which sits between the UI and the actual business tier.

This kind of comparison of various design and architecture strategies is what I would like to see in your book.

>Look at it this way, Active Documents are in the product, but nobody who has a clue would actually use them.

Rick Strahl makes effective use of Active Docs for a few maintenance forms that can be run in VFP or called through Web Connection. I think he might be one of the few people who *does* have a clue about them. :-)

>Is it the responsibility of business objects to open tables?
>Or.....
>Is the the responsibility of a data-services tier component to open tables?
>I think a better approach is to have a business object create an instance of a data services tier component, and have that component do the work.

Here I'd like to see perhaps a comparison chart or listings of the pros and cons of each approach. We hear "data tier" vs. "business logic tier", but seldom see *performance* comparisons of the different approaches.

In Erik's example, is there a performance hit if he puts the table opening and access code into a separate data tier component? How does performance weigh against purity of design and ease of swapping back-ends? Again, this is the kind of info that I'd like to see quantitatively compared in your book -- real-life balanced against theory.