Welcome to Abstract ADO.NET!

JDBC got it right

The JDBC package got it right when they made Connection, Statement, Resultset. interfaces. This allowed people to be able to use DriverManager to get connections without actually caring about the underlying connection (other than registering the driver).

ADO.NET gets it right too...almost

This page isn't about JDBC though. It's about ADO.NET. When the PDC Technology Preview came on in July 2000, it looked like the ADO.NET team was doing the same thing that the JDBC team did. They had an interface for connections (IDbConnection), an interface for commands (IDbCommand), and an interface for result sets (IDataReader). Sweet! We can finally use good old fashion interface programming. Or can we?

ADO.NET Problems

The most heinous problem is the exception heirarchy. No matter what goes wrong in JDBC, you will get a SQLException. In ADO.NET, depending on the underlying provider is what type of exception you will get. Using the SqlClient classes, you will get SqlException. Using the OleDb classes, you will get OleDbException. Using the Oracle classes, you will get OracleException. And so on and so forth.

After the exception problem is the creating of connections. There is no factory for creating connections so you have to litter your code with the specific connection type that you want to create. Once you get the connection, you can start using the interfaces (albeit with the exception problem above). But what if you want a DataAdapter to fill a DataSet? As with connections, there is no way to create a data adapter without knowing the concrete ADO.NET Managed Provider.

Solution

The solution to these problems is Abstract ADO.NET. It is a series of classes and interfaces that make it possible to create connections without having to know the underlying provider. The main interface in the package is IDbConnectionFactory. This interface allows you to create connections without regard to the specific provider. There are implementations of this interface for the SQL Server managed provider as well as the OLE DB managed provider. You use them like this...
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
SqlConnectionFactory sqlFactory = new SqlConnectionFactory();

//
// setup sqlFactory
//

IDbConnectionFactory absFactory = sqlFactory;

// Create connection
IDbConnection c = absFactory.CreateConnection();
try {
   c.Open();
   // do something with connection
}
catch(DataException) {

}
finally {
   c.Close();
}

Notice that we catch a DataException instead of the specific provider exception. This is because the connection returned is actually a wrapper around the provider connection. Of course, you might also notice that a SqlConnectionFactory is created directly. This ties the code to SQL Server doesn't it? Yes it does. But Abstract ADO.NET comes with a series of Configuration Section Handlers. So you can add into your applications configuration file what type of connection factory to configure. There are samples in the project.

Todo

What exists today is verison 0.6.3. It contains the following -

Factories for SQL Server and OLE DB
Configuration Handlers for SQL Server, OLE DB, and a collection of the latter factories
A Mock implementation of the ADO.NET interfaces.

What we need to do for the future is -

Wrap Command objects
Wrap Data Adapters
Wrap Data Readers
Extend the Mock framework to data adapters
Provide a factory framework for data adapters

Help out

If you are interested in helping, shoot an e-mail to the project admin. We'd love to have you.

Project

You can find the project here.