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.

Sometimes, we need someone to remind us, we’re doing it wrong.

Here’s my quick list– you’re doing it wrong if:

• you’re not using ORM.
• you’re using (ADO.NET) data sets
• you’re not refactoring
• you can’t deploy in one step
• you’re not always learning.

stop doing it wrong, start learning how to do it right:  AgilePakistan.org

The end of RDMBS is near! This isn’t another ORM rant, but let me be honest: I don’t like relational databases and I can’t wait for the day when I don’t have to read another query. RDBMS don’t fit our model of computing.

Working with the object oriented paradigm you quickly realize that your objects don’t fit in relational databases—they’re square pegs and your database is a round hole. RDBMS came before object oriented programming, before the web; our requirements have changed since the 70’s. So we’ve invented pretty toys like Active Record and NHibernate to fit our square pegs into databases but in the end they’re kludges, elegant kludges because we’re still stuck with RDBMS.

In 2008, how do we use databases? I bet most of us use them to only store data? For many of our applications we need key lookups, easy scalability, ability to store massive amounts of data and none of the other overhead that is associated with administration. Enter Document Oriented Databases– Imagine giant hash tables floating in the sky, no schemas or tables. No fixed data types, just keys and data. CouchDB and Amazon’s SimpleDB are two such database systems, which happen to be built in Erlang. You can read more about CouchDB, but the important thing to know is that it’s a distributed database system which works well for semi-structured data.

Now imagine this Reduce(Map(F(CouchDB)) and Bam! If you think I’m doing a lot of hand waving here, I am, but look at Google, what makes their infrastructure so scalable? How does Google achieve their massive scalability? BigTable and Map/Reduce! Document oriented Databases and Map/Reduce are changing the way we look at scaling and Map/Reduce is quickly becoming the essence of scalable high-performance computing (and the end to RDMBSs).

There’s a lot more to this, where it’s headed I’m not sure, but it’s making my spidey sense tingle. There are other closely related topics that should be explored, column oriented database and Hadoop, but that’s for later, I need to breathe.