This post originated from an RSS feed registered with .NET Buzz by Peter G Provost. Original Post: Data Access Application Blocks 3.0 Released Feed Title: Peter Provost's Geek Noise Feed URL: /error.aspx?aspxerrorpath=/Rss.aspx Feed Description: Technology news, development articles, Microsoft .NET, and other stuff... Latest .NET Buzz Posts Latest .NET Buzz Posts by Peter G Provost Latest Posts From Peter Provost's Geek Noise

It looks like MS has finally acknowledged the core flaw in ADO.NET. Here's the deal...

In System.Data there are the following interfaces:

• IDbConnection
• IDbCommand
• IDataReader (why it isn't IDbDataReader I don't know)
• IDbDataAdapter
• etc...

The nice thing about this is that you should be able to program against the database transparently, right?

WRONG!

Here is the core problem:

IDbConnection doesn't have a CreateDataAdapter method. So there is no way to "know" which kind of Data Adapter to use given only an IDbConnection. This sucks. You can call IDbConnection.CreateCommand to get a command object. From the command object you can get a data reader. But to fill a DataSet you are hosed.

Well, if you haven't already written your own factory code, the new Data Access Application Block is out and they have done it for you. It looks pretty good at first glance but I haven't banged on it hard.

I can't believe we have to go through all of that just because the ADO.NET team forgot one method...

(Found the DAAB 3.0 via Fabrice's Weblog.)

PS. This is the first bit of code I've seen come out of MS that has and NUnit test harness with it. Very cool. Keep it up.