There has been a good deal of buzz over the last couple days about DataSets and their use for representing data across boundaries.

See here, here, and here.

I particularly like Scott's analogy that domain object is to DataSet what Apple is to a Bowl of Apple Descriptions.

I have what may be considered an old school, minimalist view on this matter. In fact, it is very similar to the movement in the Java community towards POJOs and away from heavyweight containers and intrusive abstractions, both of which comprimise one's domain modeling ability and freedom. DataSets, DataReaders, DataWhatever instances should seldom cross tier boundaries, especially never across application boundaries, and certainly should never allowed to leak into the business tier. (There are some exceptions to this guideline, for example within data-oriented applications where a domain model either does not exist or whose sole purpose is to facilitate interactions with the data tier (e.g. ad-hoc reporting applications).) These are simply mechanisms to represent the results of data store operation, belong in the data tier and only in the data tier, and should never see the light of day outside their little tikki hut.

I am a big fan of managing interactions between the domain and data tier through Set-like patterns. A Set is modifiable, maintains identity, allows finding items which match a particular criteria, and is an easy abstraction to work with. The Set translates business-sensical operations into concrete commands to the data tier, and is then responsible for constructing domain objects and mapping data resulting from database operations. Life is simple, and the business tier and its consumers are entirely ignorant of data concepts which are of no interest. Unfortunately, the Set I describe differs fundamentally from the DataSet, namely in that the DataSet attempts to represent the domain model in addition to the data interface. While the DataSet's query and database interface mechanisms may be useful for integrating with a data store, this is an implementation detail and should be hidden as such. If the DataSet query syntax is appropriate for the business tier, for example, simply supply a query to our Set which will relay it to an internal DataSet in the data tier to perform the operation. The mapping still takes place, and the result is either a single object graph or a collection of object graphs, each of which is a strongly typed domain entity.

I understand that today in ASP.NET and WinForms DataSets make binding situations much easier, but the decision to go in one direction versus the other should be a conscious tradeoff. With the new ObjectDataSource functionality in 2.0, proper domain modeling and easy data binding are no longer exclusive choices.