DataSets are Evil
I’ve always equated the use of DataSets anywhere outside the data layer with code smell, it’s a sure sign that a proper domain model doesn’t exist; it’s also just as likely that the application isn’t layered. Lets look at some of the reasons you should avoid using DataSets.
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.
July 31st, 2008 at 11:32 pm
To be fair, you *can* use strongly typed datasets.
And you can mitigate the schema change ripples to a certain extent by doing “Select dog as dog …”, but that makes your sql gross(er?).
In any case, I mostly agree.
August 1st, 2008 at 12:16 am
IMHO, the energy and time spent creating typed DataSets could be better spent creating domain objects, with domain objects you have all the benefits of typed DataSets plus extensibility.
August 14th, 2008 at 2:42 pm
Quote: the energy and time spent creating typed DataSets could be better spent creating domain objects
Strange. I think Visual studio DataSet designer can create typed DataSets in a very less time. In one dataset, you can add multiple tables, relationships and links, table adapters to fill your data in various ways and much more. It also handles the inserts/updates/delets automatically too. I do not have much experience with ORMs but I think DataSets (typed) can be used for a very rapid development.
August 17th, 2008 at 3:12 pm
Mehroz,
Initially datasets are very easy to use, Microsoft provides a lot of tooling around data sets, but as your application grows larger Datasets require to much maintenance, and make it very difficult to extend your application, for the reasons I mentioned above.
January 2nd, 2009 at 9:19 am
[...] public links >> datasets DataSets are Evil Saved by Luffy90 on Fri 19-12-2008 Walkthrough: Integrated authentication and your report [...]