Datasets Vs. Custom Objects

posted on 10/31/07 at 10:56:52 pm by Joel Ross

A few days ago, we got a question in the discussions for the NuSoft Framework asking, "Why not just use a strongly-typed DataSet?" Honestly, I was a little taken aback by the question. I haven't used datasets or typed datasets in probably 4 or 5 years, so I guess I wasn't even aware that some people were still choosing datasets.

My views on Datasets

Having used typed datasets a little bit in the past, my experience was that they gave you a lot of good functionality. It's easy to create them and it does a good job of extracting the database interaction away from the developer, but there were still a few issues that left me searching for a better solution:

  1. Adding functionality: While using datasets, you get a lot of functionality created for you. It gets you 80% of the way there, but adding that last 20% can be painful and the code is difficult to maintain.
  2. Database changes: I have yet to work on a project where the database didn't go under changes throughout the project. As we've done more and more agile projects, the database changes are much more frequent as we add new pieces of functionality. Having to recreate the typed datasets becomes a pain.
  3. Programming interface: While there are probably a few tools that can alleviate the above problems, I never spent time looking for them because I'm not exactly thrilled with the interface provided - it's not how I want to develop software. When I'm writing code against a dataset, I feel like I'm spending more time working (or fighting) with the technology of datasets than I am working with my domain.

Enter CodeSmith and Code Generation

Because of the above issues, I started using hand-written custom objects. This was back in the .NET 1.x days, so the first thing to figure out was how to have a typed collection. Because they're such a pain to create manually, I turned to CodeSmith because it's collection generators were well regarded.

Once I was used to CodeSmith's syntax, I started to realize the power it has when connected to a data model. I quickly realized that most of my business objects look similar - the differences were in properties and the "guts" of the CRUD methods - and the differences correlated directly to the differences in the tables that held that data. Since CodeSmith can get at a lot of the metadata in a database table, it was simple to create a quick custom object template that I could use to get started. From my above issues with datasets, this solved two of them. I was able to define my own interface, so it was exactly what I wanted to develop against, and adding functionality it easy - It's a standard class, so I'd just add new methods. It wasn't until later that I figured out how to deal with the last issue. Once I moved most of my development to .NET 2.0, I was able to do what I wanted by generating partial classes.

The NuSoft Framework was born

Around that same time, there was a push at NuSoft to standardize our development efforts - a few of us had been leading projects and doing things pretty much the same, but slightly different. We got together and worked out our differences, and the end result was a set of CodeSmith templates that we could use for our projects. The code was familiar to all of us, and we could easily extend it while still being able to re-generate whenever we needed to change the database.

About a year after using the NuSoft Framework internally and tweaking it, we released it as an open source project on CodePlex. Since then, it's evolved a bit and we are still actively using it internally. On the projects I've used it on, it solves all three of the issues with datasets: It's easy to add functionality, I can re-generate at any time without losing changes, and when writing code against it, I feel like I am working with my domain and not with the technology.

What others are saying

When I got the original question (way back before I started rambling!), I hit up "my peeps" to see what their opinion was - using Twitter, of course! I didn't get a ton of replies, but I got a couple. The first was from Scott Coon, but the link he provided doesn't seem to work anymore. I searched around, and I think he was referring to a couple of posts that are mainly focused on performance differences between the two.

The other response was from Keith Elder, who didn't really answer, but he did put up a full fledged blog post about it. If you read through it, "The Elder" makes a strong argument for plain datasets. But when expanding his scenario a bit, he starts to lean back towards custom objects:

Maintaining customer information in just a Dataset scenario is slow, lots of overhead and isn't near as clean as just a plain old C# object (or entity, however you think of it).  We can wrap our Customer entity with policy injection and validation much cleaner than we can trying to represent a Customer in a DataSet no matter how we look at it.

Basically, he favors datasets for simple scenarios because of their ease of development and not needing to write custom code for things such as filtering and sorting. My issue with that is that by using a solid framework, that code can be created automatically. Sorting is built into the NuSoft Framework, and filtering isn't built in, but could be done in just a few lines of code using pieces that are generated. He does, however, make a very valid point when talking about displaying a list of just a few of the properties, since most object frameworks populate full objects.

To be honest, looking into this whole thing, I was surprised that people still use datasets at all. I remember the argument back in .NET 1.0, and you saw a lot of code samples from Microsoft utilizing them, but more and more sample code used custom objects starting with .NET 1.1, and you rarely see any datasets with 2.0 code. And yes, I realize that code samples shouldn't be a measure of what people are (or should) be doing, but given the tendency of developers to take samples and turn them into production-ready code, it does give a little insight into how people are building software.

Anyway, as Keith says, it's all "clear as mud" now!

Tags: |

Categories: Development, C#