Data Access Code Now and Then

Talk about interesting timing. Dino Esposito is asking: How were you writing data access code five years ago? I was thinking about it just the other day.

In the beginning Microsoft created DataSet. Now, DataSet was rich and juicy; it allowed creating an offline copy of a record set. And Microsoft said, let us also make DataView in the similitude of DataSet to project a filtered and sorted view of data in a DataSet. It was good, and Microsoft rested.

Raw DataSet

DataSet is a great class. It tracks what has been added, removed, modified; you can commit or reject these changes; you can sort it and filter, and so on. Five years ago there was little prescriptive guidance; managing data access with DataSet was en vogue. If you looked at Vertigo’s “port” of the Java Pet Store there was some crazy stuff going on—open DataReaders were thrown across tiers to the UI. Also, if you looked at the early Enterprise Samples, Duwamish and FM Stock, you saw the same thing—at was all DataSets and DataReaders (I studied both carefully).

Then custom collections began to creep in through articles and word of mouth. ORM and code generation tools were in their prime, so creating custom collections was next to rocket surgery.

Fast-forward to 2005: custom collections is the name of the game now! Why did DataSet fall away from the grace?

Microsoft has put out a tremendous amount of architectural guidance; gotta hand it to them. Also, developers have come to realize that a DataSet is not the best way to model real-life entities and their relationships. With DataSet you operate on tables, rows and columns and can’t break away from thinking in terms of database fields. For example:

AuthorName.Text = 
       Convert.ToString (author.Tables ["Authors"].Rows[0]["Name"]);

All this to display the name of a hypothetic book author! Do this several times on one page, then multiply by—say—100 pages and you go insane. Some people call this “business logic”, but to me this is anything but business logic. Great as it is, DataSet obscures the nature and purpose of data you manipulate.

Couple that with the fact that value types get boxed and unboxed in a DataSet. If a primary key happens to be a Guid this is going to look ridiculous:

Guid pkid = new Guid (
    author.Tables ["Authors"].Rows[0]["PrimaryKey"].ToString());

Strongly-Typed DataSets

To ease the pain, you might want to stick with a strongly-typed DataSet a friendly VS.NET wizard creates for you. This is a little better, because the code doesn’t look as messy:

Guid pkid = Library.Authors[0].PrimaryKey;

Strongly-typed DataSets come with a bag of issues:

• The class is sealed and you can’t extend it. Bummer!
• The class is too large—the amount of codegened code is insane.
• You can’t specify its base class.
• Horrible when it comes to dealing with nulls.
• The class exposes the raw underlying DataSet, etc.

As you see, strongly-typed DataSets are half-baked and can be used only in severely limited ways.

Collections

Personally, I think collections do a better job of expressing real-life entities. With custom collections you get much cleaner code, better expressiveness, and—what’s really important—abstraction from the underlying data storage medium. Sorting and filtering doesn’t come right out of the box, but it’s not that difficult. In fact, if you settle on a code generation approach, you get other code to produce comparers and filters for you. Custom collection have some upfront cost (time and effort) to get them all created, but this investment pays off in the long run.

In the big 2.0, generics will help with custom collections, so you won’t have to monkey around with BaseCollection just to avoid type casting.

The way I see it, DataSet and it’s related classes will become second-class citizens and will do what they do best—shuttle data. I also think custom collections will move way beyond merely overriding BaseCollection as ORM and codegen tools shift into high gear.

Asking that question works for more than just data access. I frequently find myself looking back on how I used to do all kinds of things. And then I look at how we used to do active server pages. ;) It certainly highlights how far we've come.

ASP.NET (and thus ADO.NET) wasn't publicly made available until 2002 which puts the beginning you mention at 3 years ago and not 5 years ago like Dino asked about. 5 years ago would've been plain 'ole ADO and ASP 3. As we all know, ADO was all about the RecordSet.

Chris, beta 1 was available in the fall of 2000, and it was quite stable. You're right, though---ADO and ASP 3 ruled the space at the time.

I just wonder how many of us actually used Beta 1? I know I didn't personally.

duwamish sounds funny

good article!