>
>5. There is no “sense” of n-tier design. You code against an object with CRUD methods. It internally may have a data layer, but that’s hidden. Business rules/processes/workflows are built into the objects themselves (since the transaction root is the object). You ‘typically’ wouldn’t have a business and data tier in this case; you just call methods on objects from the presentation tier.
>

Let me take another stab at this one. This comment, "You ‘typically’ wouldn’t have a business and data tier in this case; you just call methods on objects from the presentation tier", isn't correct. I wouldn't typically do something like this. Form objects delegate to the form, the form delegates to the business objects. The business object delegates to business rules for validation. CRUD is delegated to a data layer (which delegates to various providers). Of course, that's "hidden" - that's the point, isn't it? If they'd prefer an ORM way of dealing with business objects and data, that's coming in a later release. This >is< a logical N-tier design.