Typed DataSets versus Domain Model

Recently I worked on a project that used typed DataSets as a domain model. Because of my experiences on the project, I decided to post about the usage of typed DataSets for domain modeling. I personally didn't have much experience with typed DataSets since I always preferred classic domain modeling using good OO principles and user-defined types, so this was a nice new task.


Initial Thoughts
When I started on the project, my first task was to create a WCF persistence service. This persistence service would interact directly with two typed DataSets in the way of classic CRUD.

My initial thoughts were the use of typed DataSets were pretty nice. It was quite easy to populate them from a resultset retrieved from a SQL Server database. The built-in support within the ADO.NET API was nice. Built-in support for simple data validation (not allow DBNull and such) was nice. Overall, my first impression was that typed DataSets are nice to work with, almost fun.


Reality Set In
Those thoughts quickly waned. What I started to find is that typed DataSets allowed inconsistent behavior when using them; for example, you can set a column's AllowDbNull property to false but then set its default value to DBNull.

Continuing on, I discovered other problems that I consider serious. One is a very simple modeling issue: multiplicity. Simply stated, you cannot enforce a 1:1 relationship between two tables in a dataset. More accurately stated, you cannot control the multiplicity of relationships. That is, if you're modeling automobiles, and you have a Car table, you cannot enforce that the Engine table only has one record; by nature in relational models, a foreign key is 1:M, and with typed DataSets, this is no different. With classic domain modeling, this is of course trivial. There are also problems with aggregation, composition and generalization with typed DataSets as well; this will be discussed later.


Good Does Exist
There are some good things about typed DataSets that you get with using them. For one you get free ORM, which in my book is huge (restated, you don't have to do ORM since you can use built-in ADO.NET, and phrased yet another way which is that you only have two choices for ORM: manual property setting and DataAdapter.Fill). Another nicety is Visual Studio will automatically generate strongly-typed query methods on a DataTable for keyed columns when using the DataSet designer, such as GetCarByID().

Another nicety is a DataSet's built-in support for databinding. One concern with using classic domain modeling is the fact that you have to build in data binding support. What I've done to overcome this is create reusable base classes that implement the required interfaces (such as INotifyPropertyChanged), support for undo/redo, and use BindingList for binding entities to a DataGridView, however data binding with domain models is largely a manual (and sometimes complex) effort. However my experience has been that the trade off is worth it from an architectural quality standpoint.



Typed DataSets vs Domain Modeling: Which to Use?
I could probably spend another 10-15 pages about why I always prefer domain modeling over typed DataSets, but it all boils down to what adds real business value.

What I've found is that you will generally spend less time building your data layer when used typed DataSets. This is because of the fact that you can use the ADO.NET API for data access and ORM. That is, you can depend on an IDataAdapter implementation to fill the DataSet. That means in the complete interest of RAD, typed DataSets increase time-to-market.

That being said, for the reasons mentioned above, typed DataSets cannot produce accurate domain models, nor were they ever meant for such a thing. Typed DataSets work like relational databases, which do not support even basic OO principles. Of course typed DataSets are classes, so there is some support for OO (after all, typed DataSets descend from DataSet), but typed DataSets in themselves are not the entity: the tables they contain are, which is why the application of OO fails when modeling a domain.

Simply put: domain modeling with user types are the right approach to domain modeling. With user types, you can support generalization, (accurate) multiplicity, (better) code reuse and other OO principles that improve the overall architectural quality. Development teams can spend lots of time getting products to market, but the simple fact is architectural quality will have a postive or negative impact on long-term and repeatable success, and all too often, not enough time is spent on quality since its ROI is generally not measured. This is often followed by more bad code and bad architectural decisions, but that's a discussion for another day (blog?).