DataSets II

The main reasons people do not like DataSets are that they are not ‘objects’, so you cannot build a good domain model with them and that the syntax does not feel very OO (dataSet.Table[0].Field instead of Table.Field). They are also expensive to create.

Living in a relational world, I tend to be skeptical of domain models. I’ve been building Java applications for a while, and I experienced the whole cycle of trying to make a perfect domain model, using persistence tools, etc, and I think it was not worth the pain. My Business Logic/UI code was much cleaner, but I experienced all the problems Ted describes and some extra ones ;). Martin Fowler (Mr Domain Model), also has some exceptions to the rules.

I really think you should have data objects that match your use cases, that work with just the data you need, and with the structure you need. Your apps will be easier to code and the interfaces you work with will be more stable. DataSets are almost perfect for this, but you can do it without them, so let’s try it.

You need to bind your objects to the UI widgets, so you can add support for data binding to your own classes. Getting closer to what the DataSets provides involves a lot of work, so you’ll probably do it in the classes that require it (which, of course, ends up being most of them).

Then, you will need support for optimistic locking, and you will build that in your domain classes. It’s already built in DataSets.

You could need to have an untyped way to access the objects, so you end up using reflection to get/set some public properties. You can always use the untyped DataSet.

You will want to serialize it to XML, which should be easy as System.Xml.Serialization.XmlSerializer will serialize any object, but it’s really not that simple. Do you have private fields? Do you want to serialize them? Do you have cycles in your object hierarchy? You cannot have private fields or cycles in your object model if you use DataSets.

DataSets also help you to build message-based applications (the DataSet is the message), they help you to decouple data from behavior, and data from the architecture. Again, you can do this without them, but they force you to do this.
 
At the end of the day, for a complex application, you’ll probably end up coding a lot of the stuff DataSets already have. I’m glad to give up my coding aesthetics and some extra CPU cycles for the flexibility they give me.

Of course, when you need to use them to go outside your application's boundaries, you will read this and know what to do.