After writing DevelopMentor's Essential OLE DB class and teaching it to provider writers (and detail-oriented consumer writers) for a few years, I always thought that a good way to get myself acquainted with the new data model was to write a new database client provider/driver/etc whenever the model changed. I wrote a simple .NET data provider during .NET alpha 1 and published an article in MSDN magazine about it in Dec 2001. Well, the model changed again.
ADO.NET 2.0 enhanced the data provider model in some pretty revolutionary ways. It added something that was always needed, a factory for providers. This class (System.Data.Common.ProviderFactories) gets a list of providers or a provider-specific factory class (e.g. SqlClientFactory). The provider-specific factory can be used to get provider-specific Connection, Command, etc, instances. Providers that want to participate now have a special place in the config file. The 4 Microsoft providers are listed in machine.config.
In addition to this change, the new provider model is based on base classes rather than interfaces (although interfaces are still there for backward compatibility). Provider writers implement classes that derive from DbConnection, DbCommand, etc. This allows adding new functionality without breaking backward compatibility.
So I've updated the provider and posted the update on my website. The updated provider uses base classes and also has a Provider Factory class. There's also a sample program that uses it. I didn't put the provider in machine.config, but have an app.config that adds it.
An overview of the new model is provided in this MSDN online article, and two more are in the works. Look for them in MSDN online.
Enjoy.
3 thoughts on “A sample ADO.NET 2.0 data provider”
[begin rant]
Am I crazy, or am I the only one who seems to care that ADO.NET 2.0 fixes almost everything about heterogenous data access except for one CRITICAL piece: a common base esxception class!
How are we supposed to do access to unknown providers without knowing which exception class holds the database exception? Because there’s no common root, you’re stuck catching Exception.
Eek!
How about – like, er, JDBC – we have a base class or interface AdoException or DbExeption or the like, so that we can get at the general cause, native error code and the (sometimes very helpful) SQLSTATE code.
Or if they really want to make us super happy, support an exception provider that can throw useful things like DuplicateKeysException,
ReferentialIntegrityViolation,
ConnectionFailureException,
et cetera.
Imagine writing a message broker but being unable to know if your message processing failed due to configuration, temporal state (e.g. log full), or something presumed to depend upon message content (RI violation)…
instead of smart error handling you fall back to the poison-message-retry-count pattern…
gee isn’t it smarter to leave the 100,000 messages in your queue alone if you can _know_ that the required resource (database) is simply unavailable?
[end rant]
Whew, I feel better.
Sorry to dump in your log, but I’ve been carrying that one around for a while.
Thanks 🙂
– Dave
The link in the last sentence does not work.
The link in the last sentence is fixed/updated now.
Cheers,
Bob
Comments are closed.