I have long advocated using custom objects instead of DataSets as the foundation for organizing business logic. As you noted, moving all infrastucture (including data access) out of the business object is beneficial on many levels.

I have not read the Lhotka book but I can tell you that Fowler (usually) recommends a domain model for organizing business objects which are not built on DataSets.

We are now entering a period where there are many good object-relational mappers on the market that will make using a domain model just as easy as using the DataSet. You can get real business objects, true object-orientation and rapid application development without the DataSet compromise.

>>> Anyway, just curious ... can you summarize some of his objections?
>
>Basically he is trying to prevent having the same business logic in several areas. In a 3 tier design, developers have most business logic in the “business object layer” but will typically also include logic in the UI (or even the data access layer) for “better” user experience. His approach is to move all business logic into the biz object and serialize it back and forth (the DAL becomes an app server that just calls-back the biz object). This is where it differs from the “normal” 3-tier model. You can serialize datasets (which are very fat) but you still have business logic elsewhere – not good design. I believe his code, using a DataReader, is even faster that a DataAdpater with a typed dataset (but I have not tested it). There is a LOT of other issues, such as Security Principal the biz layer and DAL are running on.
>
>The first chapter or two really goes into the reasons and I recommend the book for at least it. You really should read the book. In fact this is the first Apress book I would recommend (many bad experiences(.
>
>I disagree with some of his approaches -- mainly with design patterns and would like to see more component based (i.e., using interfaces). I would like to combine this approach with Martin Fowler’s enterprise patterns. I still new to patterns.
>
>John