Karl Seguin

.NET From Ottawa, Ontario - http://twitter.com/karlseguin/

Revisiting Datasets

(Apologies for the relative lack of posts, I’m working on something brand new which I hope to be able to share with the community in the coming month…stay tuned).
Warning: this might come out as a ramble of thoughts….

I was doing some light research tonight about domain layers and dataset, when I came across a promising (j/k) hit on Google titled DataSets Suck by Jacob Proffitt. I figured this was just the kinda FUD I needed.

I was surprised to see my own name come up and a link to my How to Hire a Programmer post. Reading the post, Jacob is obviously a really smart and open minded guy. His very last sentence was a little rough, but even so, I think he’s dead on (about the last point and everything else as a whole).

Jacob doesn’t like that we “real” (his word, not mine…I think) hate datasets but never give concrete reasons why. Part of my hatred does come from personal experience where a complex system, with DataSets as the foundation, was totally molested.

The real reason though is actually much more complex and not really related to DataSets as a technology at all. You see, DataSets are just too damn easy and programmers too damn lazy. Unlike Larry Wall, I’ve long stopped believing that laziness is a sign of a good programmer. I advocate against the use of DataSets as a counterbalance to people who blindly use them.

There are many situations where DataSets are a very useful tool, and many ways in which to leverage them in other situations where they might not be the go-to technology. But it requires knowledge and experience to make that decision and far too many developers stopped acquiring either after reading their first .NET reference book. Object-impedance mismatch is something developers should understand as are O/R mapping, OOP, N-Tier and domain drive design.

So yes, Jacob is right; my complaint isn’t with DataSets, but the abuse of DataSets, not knowing about alternatives and their pros/cons. The same could be said about almost any technology (like exceptions, string formatters, http handlers, codebehind and so on). For its part, I think Microsoft has been responsible for the lack of education, yet I’m hopeful LINQ will start to change that.

I hope the pro-DataSet people appreciate my position and understand my attitude. I think most knowledge DataSet proponents would agree the pendulum often swings too far their way.

Published Feb 24 2007, 08:48 PM by karl

Filed under: Short Outbursts

Comments

Kevin I said:

We are using typed datasets for our business object data storage medium for our current large scale application. And with the timeline, and with what I want to do, it would not be possible to use custom objects in this way. We do not use the auto-adapters. We just make the datasets, and build them from a sproc we make. We have our own custom update methods in the dal (so we can have a sqltransaction and use our utility methods to handle issues like identity fields after an update accordingly). We also do not use the partial class stuff for the typed datasets.

The things I think are great are:

- Relationships are very flexible and are great to have, and use

- The integration with the winform layer is very easy and straightforward, and the dataviews, selecting, filtering, grouping is great stuff. And the way the rows store their prior versions before you accept and such is just great.

- With the general dataset, we have a small utility class we made for working with it, which helps us abstract out some basic stuff, and add some 'attributes' that we can use for all our datasets (WriteOnce property).

What has helped us manage these is having them wrapped in a business object that we write. So we have an object which is given the dataset name in its generic definition (so it knows where its data is sourced against). Then we add our functionality as needed. We programmatically add any relationships, defaults, and such. We do not put any of that stuff in the designer. We just use the dataset designer to give us a typed object to use. And we keep that other stuff out so we can just drop a new sproc output for a table on there if we update an existing table.

Our interaction to webservices are done by us using a utility to serialize it to binary and compress it. Then we send it over the wire. Any updates only send the .changes back, so it is very efficient in our use.

This causes a bit more work, but is very easy to do. And some of the things like the calculated columns and expressions are just very useful stuff.

I've worked with a CLSA variant type of system with vb6, and although i would love to have the time to sell everyone on a real system like that - what we've managed to do with the typed dataset has been really cool. Not to mention the way we used that to build a control manager to make our bindings on our winforms more data driven (reduce form code), and even transparently add business rules as a separate object, which attach to a dataset and are automatically read by the winform for displaying errors and such.

I think people go overboard with using the typed dataset, if you think of it like a recordset in vb6 land, or as just a data container, it is GREAT. Anything more than that can cause a maintenance headache.

And we've run our systems in a stress environment for performance with no issues as far as using a 'dataset'. If you use them correctly, then can be a real time saver.

Kevin

# February 25, 2007 12:53 AM

Vikas Kerni said:

http://vikasnetdev.blogspot.com/2006/09/why-do-i-perfer-custom-collection-over.html

# February 25, 2007 8:57 AM

Jacob Proffitt said:

Thanks, Karl. I really appreciate the response. I couldn't resist <a href="http://rabidpaladin.com/archive/2007/02/26/Arguing-Data.aspx">responding back</a>... :)

# February 26, 2007 4:38 PM

Jacob Proffitt said:

Heh. Actual link: http://rabidpaladin.com/archive/2007/02/26/Arguing-Data.aspx

# February 26, 2007 4:38 PM

Bryan Wilhite said:

To me a DataSet is a poor man's "transaction container": it is a quick and dirty way to party on a set of data in memory and then commit the results of the wild party to the persistent DBMS.

Since WinForms/ASP.NET data binding is not my first choice (XSLT/AJAX/YUI is my first choice), the DataSet has very little chance of sneaking into my life beyond the parties mentioned above...

# March 1, 2007 7:30 PM