Recently I had a discussion with a developer involving in the ancient discord between using DataSets versus custom Data Transfer Objects (DTO). Personally I’m very pro Data Access Objects and exposing these as custom Data Transfer Objects in the service layer of applications. I always thought that DataSets were missing something. They are just plain containers without the possibility of any real behavior.
The current move for more intelligent objects in the Domain Driven Design paradigm seems to confirm this. I can see DataSets being applied in very simplistic applications where the presentation, required in the GUI, almost maps one-to-one to the database structure. But in any other real life enterprise application this is almost never the case. You have a business layer doing complex manipulations on the domain entities, often involving a rule engine, before these entities are exposed to the session facade.
Another thing is that DataSets and Web Services do not go very good together. You can’t say that DataSets are really platform independent, can you?
During the discussion one argument convinced me to think twice about using DataSets in future projects. The argument was the huge development costs of business entities and custom DTO’s. It is true that even if DataSets are just basic data containers, there is a lot of IDE support for them that make development very easy: ‘Free Code’ But to my opinion this support is misinterpreted as an approval to hammer ‘use DataSets – everything that looks like a nail’ the data for the presentation layer.
Some more extensive comparisons you’ll find in the articles below. For a balanced view you should check out the article by Jelle Druyts. It is written by a former colleague of mine and its promoting datasets (how dare he!).