Mulling Things Over


(I)DataSet and (I)DbDataSet

I’ve been staring at a lot of Microsoft documentation lately, trying to architect a database access layer that leverages the rather nice design tools in Visual Studio 2005 , while still giving us some hooks into a data constraint mechanism. I’m trying to stay away from the currently popular business-object-to-table-hierarchy design, since I think this is badly flawed for complex applications.

What had me baffled lately is how to wire up what I want into the ADO.NET 2.0 framework. I’ve been thinking that implementing a DataAdapter was the way to go, since this seems to be the main conduit between the disconnected world of DataSet objects and the DBMS-specific connected layer. I know I could use an ad hoc class of my own making for this, but would like to try integrating into the framework to see what that gets me.

A little while ago I realized one reason that I’ve been spinning my wheels. It’s Microsoft’s documentation. It’s terribly confusing in this area. Usually, I find Microsoft’s API documentation to be OK but incomplete, but the documentation for these adapter classes and interfaces seems almost deliberately obfuscatory.

There are two key interfaces here: IDataAdapter and IDbDataAdapter. The first is designed to work with DataSet objects containing multiple DataTable objects. The latter is designed to handle a single DataTable — yet it derives from the first. There are two related classes, DataAdapter and DbDataAdapter, which implement the respective interfaces. The classes deal with multiple and single DataTables, respectively, just like the interfaces. And again we have the odd inheritance relationship. What’s worse — much worse — is that the documentation for upper layer (IDataAdapter and DataAdapter) constantly refers to features of the lower layer (IDbDataAdapter and IDbDataAdapter), giving the impression that the upper layer also can only deal with one DataTable per adapter instance. Supplemental MSDN articles suffer from similar confusion. Almost all of these articles talk about single-table data adapters, sometimes referred to as table data adapters or table adapters. Only passing mention is made of multiple-table adapters.

(BTW, these interfaces and adapters are in the System.Data.Common namespace, implemented in the System.Data assembly.)

So if you’re in the business of writing code related to ADO.NET 2.0 framework classes, be aware of the confusion in the documentation, and don’t let it become your own confusion.

Oh, and here’s another fun detail that I just discovered, using Lutz Roeder’s Reflector. If you disassemble the key public methods of DataAdapter, you find that all of the following have non-implementations that merely throw a “not supported” exception:

* Fill (DataSet) :Int32
* Fill(DataTable[], IDataReader, Int32, Int32) : Int32 (but only if given more than one DataTable)
* FillSchema(DataSet, SchemaType) : DataTable[]
* Update(DataSet) : Int32

There is no hint of this in the API documentation. In fact, the documentation for Update() is one of the first offenders I’ve seen yet, with a bunch of verbiage that is almost entirely related to a single-table update. Example: “If INSERT, UPDATE, or DELETE statements have not been specified, the Update method generates an exception.” There is no way to specify such statements in a DataAdapter!

Leave a Reply

© 2020 Mulling Things Over | Entries (RSS) and Comments (RSS)

Design by Web4 Sudoku - Powered By Wordpress