tools of data, for data

What is this?

This is a .NET multi-tier data architecture that enables programmers to write modular code for loading and persisting relational, multi-table datasets to/from various data sources. This set of classes implements a lot of the ideas laid out in the article Designing Data Tier Components and Passing Data Through Tiers. This is for any .NET developer who has ever wondered why they can't do the following:

Load(Dataset);
// add, update, delete rows in multiple tables with
// multiple relations, primary keys, autonumbers
Save(Dataset);

How can I use it?

I used this library at work, and you're welcome to use it as well. But even more, you are welcome to look through the source and the example code, gut the parts that are useful to you, and make your own data library.

The library is very small and simple. The source amounts to maybe a couple thousand lines of code. But it still addresses a lot of familiar, recurring concepts in ADO.NET:

Download

Download a zip file containing the source and a simple example application.

I've also made the documentation available, although you can build it yourself using the NDoc file I've included with the source.

A Brief Parenthetical

I think most ADO.NET developers who write at least medium-sized applications have encountered these same challenges, and probably have written their own versions of a ubiquitous data library. Maybe it's meant as a right of passage - we all read articles like Designing Data Tier Components and Passing Data Through Tiers and Application Architecture for .NET, and gain a more thorough understanding of data access and manipulation through the various layers of an application.

I was excited to attend TechEd 2004 because I wanted to see what kind of changes to expect from ADO.NET 2.0. I hoped some of these architectural problems that we devlopers face would be addressed. But except for a few new neat tricks, none of the ADO.NET 2.0 talks impressed me much at all. More than anything else, the presenters touted the feature that "ADO.NET 2.0 won't break your ADO.NET 1.0 code".

Imagine my dismay! What of the fate of middle-tier architecture design!? Where did the dream of seamlessly persisting complex objects to data stores go? It was with this mindframe that I attended a talk about ObjectSpaces and was summarily blown away. Visual tools to build xml schemas that map business objects to data sources! Querying using an XPath-like syntax! A single .Persist() method for an entire hierarchy of objects! It was a data-architect's dream come true.

The talk generated a lot of excitement among the attendees - until someone asked about the release date of this technology. Turns out it is going to be part of WinFS, which recently became delayed even past Longhorn. So until then, keep reading those MSDN articles and building those custom data libraries.

UPDATE: It's 2006 now, and as far as I know, MS still hasn't delivered. However, you will find ideas similar to what ObjectSpaces would have delivered in application frameworks like Ruby On Rails.