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

I found an interesting discussion here:

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=43315&discussionID=12708606&goback=.anh_4开发者_JS百科3315

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?

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.

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.

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.