Wednesday, June 29, 2005

DataSets vs O/R Mappers (aka: Apples vs Oranges)

I was in the middle of writing a reply to a topic at the ASP.NET forums when I decided, hey, why not be greedy and post it on my blog? ;)

The topic is about "Defending the DataSet".

SeanSmith makes some good points. Some of the same points I've seen other smart developers make in defense of the DataSet. In my opinion he's missing the boat though. The post comes off as if he's presenting the DataSet as an alternative to O/R Mappers.

In reality you can't compare the two though. An O/R Mapper is incredibly complex. A DataSet, lets face it, is not. Even with all it's features it's really just a relatively simple bag o' data. They aren't interchangeable. I can easily refactor an application to switch between different O/R Mappers, say for example between LLBLGenPro and NHibernate. It's really not all that difficult of a task if I haven't let O/R Mapper specific code seep throughout my application. I can't on the other hand refactor to a DataSet. A DataSet doesn't do anywhere near the same thing. I'd also need to pickup some code-generation templates, tweak 'em, wire up my objects, and even then I'd probably still need to write a good bit of ADO.NET.

The reverse is equally true though. I can't take an application written around ADO.NET and DataSets and refactor it to an O/R Mapper easily. I'd be cutting out huge swaths of code, and unless I had very robust tests, there's a pretty strong bet that there's a good deal of logic going on in Queries or StoredProcedures that might not be immediately apparent in the context of trying to migrate to a Domain Model.

So overall I agree that it can seem like all you hear is "use an O/R Mapper", but there's a good reason for that. Using a DataSet for an Application, one that could be modelled, can easily result in a few "bad" things: Spaghetti Code, Database Driven Design, and Obscured Intent in Code. All of these are generally maintenance issues in my experience.

Is arguing this going to convince anyone who'se not willing to at least try Domain Driven Design though? Probably not. So I'll just take it as a given that you agree that there are definite benefits to the practice, and you'd like to learn how to gain them easily. The answer is, in the vast majority of projects, an O/R Mapper. Yes, there are exceptions, and yes, everyone thinks their project is it, but unless you're very experienced with such designs the truth is, it probably isn't and you should be using an O/R Mapper.

What's the flip-side though? Can O/R Mappers replace DataSets? No. They can't. Think back to what a DataSet is: Just as simple container for data. So why would an O/R Mapper even need to replace them? Simply put, most don't even try. Some choose to implement their own ITypedLists or maybe even return the most basic of data structures, an array of arrays, but many will just use DataTables and/or DataSets if they even have any reporting features at all. And that's where a DataSet shines. As a data container. For reporting, for communication, for migration, whatever the case, a DataSet is wonderfully suited to these tasks.

This is why I find such posts annoying to be honest. I know Sean had the best intentions, and he seems like a sharp guy, but so many people aren't on his level yet. Is there really any more need to validate the opinion that a decent O/R Mapper and Domain Model is unnecessary in all but the simplest applications? Isn't there enough of that going around? A DataSet is a nail, a Business Object is a screw. Sure, there's some bit of overlap, but by and large they should be filling completely different roles in your average Domain Driven Design, and ne'er the twain shall meet!

So the real argument doesn't seem to be so much DataSet vs O/R Mapper to me. If you're using business objects extensively, you better have a damn good reason for not using an O/R Mapper if you're using a relational database for persistence in my opinion or you're just burning money.

If you aren't using business objects though, if you're a former or current ASP Classic developer, then there's a good chance you're dealing with Database Driven Design and you may have never even seen a good Domain Model (or probably didn't understand it if you did since it's not something most people pickup after a quick looksey the first time). If that's the case, then the real argument is about the benefits of Domain Driven Design and Object Oriented Programming I think. That's a topic for another post though. It's almost midnight. :)
What is Database Driven Design?
It's just my own label for an over-reliance on data-modelling and using the database as the answer to every problem.

When you see a single layer design that uses StoredProcedures working under the mistaken notion that they constitute a Tier on their own, or every new change in the problem domain requires a database change, then I'd say you have a Database Driven Design.

For example, some developers seem to love storing derived data such as if an email address for a user is valid.

Why include a column when this can be quickly and easily calculated on the fly and there is no aggregated reporting required?

Another symptom might be an overreliance on the database for application configuration. Should connectionStrings or the IP to the mail server be stored in a database for example? Believe it or not, before .Net came along, some programmers I've worked with preferred this because they never bothered to learn just how easy it was to use XMLDOM.

Some programmers still haven't made the shift, and it shows in how they use (and abuse) the database IMO.
Sam Thats an awesome article. Very nice, keep it up
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?