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.
Related posts:
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.
James Thigpen - 31 Jul 08 at 11:32 pm
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.
Shey - 1 Aug 08 at 12:16 am
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.
Syed Mehroz Alam - 14 Aug 08 at 2:42 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.
Shey - 17 Aug 08 at 3:12 pm
With .Net 2.0, DataSet does allow you quite alot of things. Strongly typed datasets are already there. And you can definitely bring in a business logic layer will that.
Combining with commercial realities, Dataset does come out to be a winner at many times, OOP classes are quite cumbersome most of the time.
Beenish - 24 Apr 09 at 12:35 pm
Speaking of commercial realities, you’ll get a web application up much faster with an ORM like castle ActiveRecord then you would with plain datasets.
I don’t agree with your business logic comment, with typed datasets you get type safety but you’re still building a “logic layer” that’s full of “staticy” functions that don’t represent your domain.
With the “logic layer” you lose all the benefits of OOP. Take a look at the onion architecture for comparison:
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Shey - 24 Apr 09 at 12:49 pm
Just read this
Designing N-Tiered Data Access Layer Using Datasets – Part 1
http://www.15seconds.com/issue/080103.htm
So why do you say it’s not possible to do ORM with datasets ?
programmer.novice - 19 Sep 09 at 9:45 am