DataSets don’t properly abstract the database, the developer has to be intrinsically aware of the database schema, he has to know the name of the columns and the type of the columns you are returning in the DataSet.  Anytime a developer wants to use the DataSet he will have to look at the underlying query which creates the DataSet and pick out the field names used in the query.  Instead of understanding the business process, instead of adding value, your developer will be mucking around with database queries trying to figure out which field name to use. 

Additionally, since DataSets are weakly typed, they don’t tell you the type of the column, the developer must know the type of the field and cast the field to the appropriate type.  Every time you cast your run the risk the cast will fail, the value returned could be null or different type.

Since your application/presentation layer is so tightly coupled to the database your design becomes brittle and difficult to change– every time your database schema changes, it’s effects will ripple throughout your system creating a maintenance nightmare. 

What troubles me more though is that DataSets don’t give you the opportunity to create a business logic layer, because DataSets are just data containers you can’t add functionality to them.  Two DataSets can’t interact with each other, you can’t abstract problems. Instead you’re forced to write procedural code to work with DataSets and you’ve surrendered all the benefits of object oriented programming.

Most of the problems associated with DataSets can be solved by using classes that represent your domain model within a well-defined business layer, essentially your represent your data tables with classes.  ORM is immensely useful here, and I’ll discuss it in detail in my next post.

Bravo Microsoft.