Why would I want to stay away from DataSets, and what are the alternatives?

Question

I found an interesting discussion here:

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=43315&discussionID=12708606&goback=.anh_43315

Quote:

DataSets are sub-par amateur solutions to code your Data layer...Stop Using Them and learn to CODE! :)

What is your opinion of DataSets vs. just stubbing out custom classes and working with those? What are other alternatives?

Answer 1

There are many many reasons to use an OR/Mapper.

Mainly:

• It generates compile-time safe types for your tables
• Generally there is a layered area where you can add appropriate business-logic and presentation functions
• Trivialises data access (save/load, deep-saving, etc)
• Easier/better process for loading FK-related objects (depending on framework)

I could go on.

I do suggest you review, carefully, your OR/Mapper. Personally, I am virtually in love with LLBLGen Pro (but it costs money). Other people like other ones, I consider them a little crazy, but to each his own. What you really want from an OR/Mapper is:

• Flexibility
• Speed
• Layered Generation
• Support across frameworks (CF, etc, if relevant)

So review on your own, and make a determination.

Answer 2

Snobbery aside, DataSets can be useful in applications with relatively straightforward business logic and where the developer has some control over the database schema, such that data tables match 1:1 business objects (which in this case are usually comprised of a DataRow).

Martin Fowler discusses this very clearly in Patterns of Enterprise Application Architecture (Amazon link). DataSets (Table Module in Fowler's nomenclature) are a good match to a Transaction Script, whereas a Domain Model requires more well defined classes and a mapper to the database (because a 1:1 correlation between business objects and tables is typically not achievable in this situation).

DataSets/Table Module have a lot of limitations, but they have advantages in simplicity, especially if you are working in .NET.

A pragmatic programmer will assess the requirements of a given application and apply patterns and technologies that fit best, even if they aren't the sexiest. For simple scenarios with straightforward 1:1 mapping to relational data, DataSets don't suck. Often, though, they do, and any programmer that relies on them exclusively is in for trouble in more complicated scenarios.

Answer 3

One big drawback is that DataSets are in-memory data structures which means the amount of memory consumed is linear to the amount of records you are returning (i.e. O(n) space complexity). On a server side app this will kill scalability.

If you define a custom class T, then returning IEnumerable<T> from your data access layer enables you to efficiently stream data from your data source (e.g. a Linq to Sql IQueryable provider) with O(1) complexity.

Note: the same problem occurs if you return List<T> or Collection<T> from your data access layer because those are also in-memory structures. I've seen a lot of people do this in the name of elegance without consideration to scalability.