RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Insulate Your Code with the Provider Model : Page 4

Find out how to protect your code from changes by taking advantage of the Provider Model, which lets you swap components at run time.

The DataLayer.InitProvider Method
The InitProvider method is responsible for creating the actual provider object that will be used. To do this you first need a field/member variable to hold that data provider. Create a variable named DataProvider of type IDataProvider. Remember that IDataProvider is the interface that each specific DataProvider that you create must implement.

The first time the InitProvider method is called it loads the provider name by reading the value from the configuration file, and then uses the System.Activator class to create a new instance of that provider. The DLL containing the appropriate provider class must already be referenced by your project for this to work:

   // C#
   private static IDataProvider DataProvider = null;
   private static void InitProvider()
      string TypeName;
      string ProviderName;
      if(DataProvider == null)
         // Get provider name
         ProviderName = ConfigurationManager.
         // Get type to create
         TypeName = ConfigurationManager. 
         // Create new DataProvider
         DataProvider = (IDataProvider)
   ' Visual Basic
   Private Shared DataProvider As 
      IDataProvider = Nothing
   Private Shared Sub InitProvider()
      Dim TypeName As String
      Dim ProviderName As String
      If DataProvider Is Nothing Then
         ' Get Provider Name
         ProviderName = ConfigurationManager. _ 
         ' Get Type to Create
         TypeName = ConfigurationManager. _ 
         ' Create new DataProvider
         DataProvider = CType(Activator.CreateInstance( _ 
            Type.GetType(TypeName)), IDataProvider)
      End If
   End Sub
DataProvider.CreateDataAdapter Method
Now you can finally look at the DataProvider class and its specific implementation of the CreateDataAdapter method. Look at the snippet below to see the class that uses the SqlClient.SqlDataAdapter:

   // C#
   class SqlDataProvider : IDataProvider
      public IDbDataAdapter CreateDataAdapter()
         SqlDataAdapter da = new SqlDataAdapter();
         return da;
   ' Visual Basic
   Public Class SqlDataProvider
      Implements IDataProvider
      Public Function CreateDataAdapter() _
         As IDbDataAdapter Implements _
         Dim da As New SqlDataAdapter
         Return da
      End Function
   End Class
While this is a very simple provider method to write, it is necessary to implement it this way to provide the maximum flexibility and reusability. This becomes more apparent when you look at the other Provider class that uses the OLE DB namespace to create instances of OleDbDataAdapters.

OLEDB DataProvider.CreateDataAdapter Method
Below is another DataProvider class that uses the OleDb native provider. Notice that this code is almost exactly the same as the SqlClient—they differ only in the provider used:

   // C#
   class OleDbDataProvider : IDataProvider
      public IDbDataAdapter CreateDataAdapter()
         OleDbDataAdapter da = new OleDbDataAdapter();
         return da;

   ' Visual Basic

Public Class OleDbDataProvider Implements IDataProvider Public Function CreateDataAdapter() _ As IDbDataAdapter _ Implements IDataProvider.CreateDataAdapter Dim da As New OleDbDataAdapter Return da End Function End Class
Try it Out
Using a Provider Model will make the code you write much more generic, easier to maintain, and easier to upgrade as Microsoft (and other companies) introduce new technology. Other areas where you should use the Provider Model include Exception Management—to determine where to publish exceptions. You could also use the Provider Model to determine where to read configuration settings from. As an exercise you could create additional providers that implement the OracleClient or any other native provider you might be using. You could have providers that read configuration settings from an XML file, the registry, a database table, or even a Web service. With a little imagination you can apply the concepts presented in this article to many areas of your application development process.

Paul D. Sheriff is President of PDSA, Inc., which provides .NET consulting, products, and services, including an SDLC document and architectural framework. Paul is a Microsoft Regional Director for Southern California. His .NET books include "ASP.NET Developer's Jumpstart" (Addison-Wesley) and several eBooks listed on PDSA's Web site.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date