DataFactory or MSDN DAAB?

As some of you may know last year I wrote a .NET DataFactory class for a TechEd presentation I did. The slides and code for the talk including the DataFactory in both C# and VB can be downloaded from the Atomic site. The class is also explained in chapter 18 of my book Teach Yourself ADO.NET in 21 Days.

In any case, this class was designed to do three things:
1) Abstract the .NET Data Provider you are using by exposing a constructor that accepts the provider name and then using reflection to instantiate the proper .NET Data Provider objects (command, connection, etc) on the fly.
2) Allow for database independent coding by abstracting the SQL statements and data types into a set of XML files that the DataFactory calls
3) Command object caching by keeping a set of static hashtables that reference command objects that have already been created. The DataFactory then clones the command object (using ICloneable) when needed to create a new command.

The DataFactory is similar to the MSDN Data Access Application Block first released in April of 2002 since they both reduce the amount of code you need to write. The difference I see are:

1) The DAAB is not .NET Data Provider independent. In their model there is a class called SqlHelper that knows how to use SqlClient. If you want other providers then you write a helper class like OdbcHelper for that (as they did in the Nile 3.0 sample app). There is no common interface they all use (which wouldn't be difficult to implement)
2) The DAAB is not database independent. It does not abstract SQL in any way
3) The DAAB caches parameters but not commands

That being said, the DataFactory would be more appropriate if you know that you need to work against multiple backends. The DataFactory is more complex because of the use of XML files and I don't believe it performs quite as well as the DAAB because of using reflection.