I recently started a new project here at Webmail.us which will be a .NET based web application. One of the core pieces of .NET web apps is, not surprisingly, ADO.NET. It is Microsoft’s upgrade from ADO, but it is more of a rewrite. Almost everything has been refactored, with many new abstractions and paradigms for how to access data. When I first read about ADO.NET, I was very skeptical. I didn’t understand the need for these complex, hard to understand abstractions like DataTable’s and DataRelation’s and DataSet’s. It all seemed foreign to me for a multitude of reasons. Unfortunately, Microsoft seems to be pushing DataSet’s so loudly, its hard to see what else is out there.
After a few days of digging though, I found a few great articles (Choosing Data Containers for .NET, On the Way to Mastering ASP.NET: Introducing Custom Entity Classes) on why not to use DataSets, as well as why you should. DataSets were designed for rapid application development, and seems to be Microsoft’s answer to the Rails ActiveRecord pattern. It is a quick and dirty way to build the data access layer for web applications. To be more specific, by quick I mean it allows version 1.0 of a product to be released quickly, because a data abstraction already exists. By dirty, I mean it isn’t an abstraction created for your application, it is a data abstraction created for any application.
Pro’s of ADO.net
Fast development time
In place architecture. Developing custom data access solutions can be very powerful, and very risky. A bad design can lead to bad performance and is inherently error prone
Feature rich
- Disconnected data
- Concurrency
- Many more…
Easily serializable
Con’s of DataSets
Large memory footprint
Not object oriented. DataSet’s represent relation data, just like a database. But I don’t want an in-memory representation of the Employee table, I want Employee objects. Scott Hanselman sums it up pretty nicely:
A DataSet is an object, right? But it's not a Domain Object, it's not an "Apple" or "Orange" - it's an object of type "DataSet." A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It's an object that knows a LOT about the Database. But I don't want to return bowls. I want to return Domain Objects, like "Apples."
- Not abstracted. Directly connected with database data and structure. So, any change to the database schema, could trickle down to the presentation layer.
Conclusion
ADO.NET is a huge improvement from old ADO, but don’t buy into the entire framework. Microsoft is trying to push DataSets but they might not always be the best solution. For enterprise applications, I don’t think DataSet’s are the answer. On the other hand, for smaller web application, it might be a perfect fit.