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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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. AppSettings["ProviderName"]; // Get type to create TypeName = ConfigurationManager. AppSettings[ProviderName]; // Create new DataProvider DataProvider = (IDataProvider) Activator.CreateInstance( Type.GetType(TypeName)); } } ' 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. _ AppSettings("ProviderName") ' Get Type to Create TypeName = ConfigurationManager. _ AppSettings(ProviderName) ' 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 _ IDataProvider.CreateDataAdapter 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.
Thanks for your registration, follow us on our social networks to keep up-to-date