Building a plug-in model to load VistaDB - Part I

In this article I will explain how to build an application that uses VistaDB and Microsoft’s SQL Server, without being hard bound against their providers directly.

Many companies desire to offer the choice from several database providers in a single product or API.  In many cases if you were directly bound, but the provider not installed, you would get a dll not found exception at startup. 

There are two ways to handle this scenario.  The most common method is to use ADO.Net Provider Factories and load the provider dynamically at runtime.  We have covered this in other blog posts.  This works great if you don’t need to use any DDA code, or any other provider specific functions.  But it is not really possible if you want to use provider level abilities.

The alternative is to put the provider specific code in an external dll, and load the code as a part of a plugin model.  Plugins can then be loaded individually and removed from consideration if the assembly fails to load (like when the provider is not actually present).  This allows for your code to continue to run, within needing the main executable to be bound against the provider.

Main Assembly Loads Plugins

For this example I am using a simple banking scenario application that can use either SQL Server or VistaDB as the backend database. The main executable assembly can not contain any provider level references directly. The main assembly for this example contains an abstract class called BankModel, a Windows Form  as the plugin Consumer, an abstract factory called PluginFactory, and the singleton PluginFactories.

The PluginFactories singleton class is in charge of loading and passing back provider specific implementations of the PluginFactory class. This ensures the provider is only loaded when requested by the user. At this level exceptions can be caught to inform users who request a provider that the provider could not be loaded.

Plugin Assembly per Provider

Each provider implementation must be contained within its own assembly, and these can be hard bound to their specific provider. This assembly implements the abstract bank model for VistaDB to handle bank transactions to a VistaDB database.

Using this separation allows for a consumer to request from any data provider, through a well known interface.

Summary

This is an overview on how to implement a plug-in model to encapsulate the bindings for database providers. There will be a follow up article explaining more about how the code works.

Part 2 of the article is over here