Dan compares Whidbey’s ProviderFactory to the one he developed for our Atomic course.  I’ve included an excerpt below, but the actual post has more details including some code snippets.

The goal of the ProviderFactory that I created was to allow developers to write .NET Data Provider independent code by providing a factory class that created the set of types necessary to work with a particular provider. My implementation followed the principle of the Abstract Factory Pattern documented in the GoF but instead of creating specific factory classes for each provider, relied instead on reflection to create the appropriate types at runtime. As a result my factory was a single class instead of a family of classes related through implementation inheritance. This had the effect of reducing the amount of code I had to write (just over 100 lines of code to support the OleDb, Odbc, and SqlClient providers) but dynamically creating the objects via reflection was slightly slower than providing concrete implementations (I did create a concrete implementation for the Compact Framework book I wrote with Jon Box to work with the SqlServerCe and SqlClient providers on the Compact Framework). My implementation then included the connection, command, parameter, and data adapter and returned interfaces from the factory methods. However, my approach ran into a few problems because the .NET Data Providers were based on interfaces rather than base classes. This manifested particularly when dealing with data adapters since the interface I was returning (IDataAdapter) didn’t include all of the members you would actually need to be able to work with a data adapter and the alternative (IDbDataAdapter) contained the command properties but not other members you would need. As a result, you had to cast from one interface to the other to get your code to work correctly.