DBProviderFactory - Old wine in a new bottle, but good nonetheless
Quite a while back, I had posted an article in CodeProject titled "Implementing a Provider Independent Data Access Layer in .NET". This article illustrated the usage of a simple provider factory, with which data access could be made generic or provider independent. The implementation was rather straight forward. Callers of the DAL (Data Access Layer) component would work only with Interfaces present in the System.Data namespace. The actual type of provider to be used in the DAL code would be determined through a config file setting and the provider factory would be responsible for returning instances of the required type .
The advantage of this methodology is that it gives you the option of (almost) seamlessly working with multiple providers like OleDb and ODBC without having to lock onto to a specific implementation like SQLClient. With the obvious advantage and seemingly simple implementation, we all could expect a provider factory to be built into the next version of ADO.NET. Well, ADO.NET 2.0 is here and with it comes the DbProviderFactory class. The implementation is fundamentally similar to the factory we discussed in my article but, there are a few important differences:
Foremost among them is that DbProviderFactory itself is an abstract base class and every provider must provide an implementation for this. The provider to use at runtime is obtained by calling the GetFactory static method of the DbProviderFactories class by passing a string uniquely representing that provider. This string is called Provider Invariant Name and is registered by each provider in machine.config. For e.g. for ODBC provider, it is System.Data.Odbc.
The second important difference is that the new provider model is based on inheritance of a set of base classes present in the System.Data.Common namespace. So, you have SqlConnection derived from DbConnection and so on. However, various IdbInterfaces we saw in v1.0 and v1.1 would still be implemented for backward compatibility. I believe the reason behind this change is that ADO.NET classes will constantly evolve to provide more features in terms of properties, methods and events. Exposing the functionality through interfaces can be an overkill in terms of maintenance in the future, wherein you maintain backward compatibility by retaining the old interface implementation, while you add new functionality by implementing new ones (analogous to COM).
For more information on DbProviderFactory, I would really recommend a good article recently published at MSDN : Generic Coding with the ADO.NET 2.0 Base Classes and Factories. This article explains in detail, all the stuff that I mentioned briefly earlier, with a fair amount of examples too.
Ofcourse, there is a lot more to ADO.NET 2.0 than the ProviderFactory. For a fairly detailed listing refer to ADO.NET 2.0 Feature Matrix. Things that catch some interest here are Provider Statistics and improvements of SQLClient wrt SQL Server 2005.