>I disagree. The beauty of business objects is that if you change your backend, your queries don't need to change because they reference the friendly property name, not the backend column name.

We use Stored Procs ... every database will have some way of implementing a Stored Proc. You still don't change anything application-wise (except your DataAccess base class may reference OleDb instead of SqlDB) ... the only thing that would be different would be your Stored Proc implementations (needing to reference different tables with possibly different column names, but would do a SELECT MyNewColumn AS MyOrigColumn and your Typed DataSet that's getting filled form the Stored Proc would be none the wiser. <g>

Business objects allow for complex relationships and adding behavior to the data.

With partial classes (and even before that, but partial classes make it easier) you can add all the functionality you want to your DataSet class.

And what about an SOA scenario? Do you want to write another layer to convert your datasets into generic lists for use in other non-.net clients? Serializing a dataset for web services becomes a huge object. Business objects are much cleaner and better separated for multi-tier development.

Same answer I gave a minute ago. You don't serialize the DataSet, you serialize the data ... a fairly light-weight alternative. (MyDataSet.GetXml() only returns the actual data as an XML string, no schema, no empty columns). Any non-.net client should be able to work with an XML string.

~~Bonnie



>
>The con is the learning curve and development cost up-front. Writing an app using datasets is quick. I tend to lean towards datasets for smaller, get-out-the-door apps that you don't expect a lot of long-term maintenance on and business objects for the more robust long-term supported enterprise apps.
>
>For dynamic queries, something similar to this:
>
>http://www.15seconds.com/issue/010629.htm
>
>The difference is I am using C# and winforms, and the addcriteria is populated with friendly business object names, not column names and the actual query is generated in another layer (after going through a mapper class that links the friendly business name with the column name).
>
>I just found by searching that there are lots of examples addsearchcriteria, addcriteria, etc... out there. I think the hibernate criteria api may be similar too.