There are many things I like about the .NET Framework Base Class Library, but of these things DataSet is most definitely not one of them. Every time I see it used I know I'm about to enter an untestable world of bad code pain. And I blame the people who write example code.
 
The web is littered with examples of grabbing data from a database, dropping it into a DataSet then binding that to a control to display to an end user. Some of the more advanced abominations will include editing and paging code. Junior developers take inspiration from this code (read: copy and paste) resulting in a mountain of badly implemented sites that turn into unmaintainable nightmares.
 
Problems with this approach include:
  • It tightly couples the database and presentation layer. Any changes to the schema need modifications all over the UI.
  • There is no business layer to speak of.
  • Because there's no business layer business logic is distributed all over the application or in stored procedures (which are their own kind of evil when used for business logic).
  • You can't unit test the elements in isolation because they can't be separated.
Admittedly you can build a system which eliminates most of these problems, but there are two important points to understand about this:
  • The most common example code doesn't. Which means most "hack it together and move on" developers won't do this.
  • If you're going to build  a proper architecture, go a little futher and use a proper domain model.
Hopefully LINQ will kill the beast, although it looks like we need to wait for LINQ-to-NHibernate to really provide a complete LINQ-based solution for ORM.