ASP.NET Provider Model Template for Visual Studio (download)

This article describes my Visual Studio 2005 / Visual Studio 2008 template for rolling your own custom provider on the ASP.NET 2.0 Provider model. The model is actually not restricted to ASP.NET and this template allows you to create your custom provider for every type of .NET application, including console and forms applications.

<UPDATE 2008-10-18>
I updated the template. I fixed a few tiny bugs, small design flaws. The template code now also validates well when using Microsoft StyleCop and Microsoft FxCop. Scroll down and download the improved download.

ASP.NET 2.0 uses a design pattern called the Provider pattern. This pattern is used throughout the whole ASP.NET architecture. Implementations based on this new pattern are for instance membership, roles, site map, session state, profile, web event, web parts and more. The official ASP.NET 2.0 Provider Model website describes the model as follows:

A provider is a software module that provides a uniform interface between a service and a data source. Providers abstract physical storage media, in much the same way that device drivers abstract physical hardware devices. [->]

Basically the model uses a static class with a certain interface that hides the underlying implementation. The concrete implementation used, is registered in the application's configuration file. If you are new to the Provider Model, check the MSDN Provider Toolkit site.

To use the Custom Provider Template, download the zip file below and save it to your local "%USERPROFILE%\My Documents\Visual Studio {Version}\Templates\ItemTemplates" directory (for instance, with Visual Studio 2005, on my computer the path is "C:\Documents and Settings\Steven\My Documents\Visual Studio 2005\Templates\ItemTemplates").

download the file:

After saving the file you can directly use the template. No need to close Visual Studio or even unpacking the file. Best is to use this template within a C# Class Library if possible, but the template will work just fine within a web application project and even a console application. In the Solution Explorer, right click on the project name and choose Add | New Item... You will be prompted with the "Add New Item" dialog box, shown below.

Add New Item Wizzard

You can scroll down and select "Custom Provider" in the "My Templates" selection. Next choose an appropriate file name. Choosing a good name is important, because the class names (and XML comments) are based on the name you select. Choose a concept name that describes your provider model. For instance, when you want to create a generic interface for obtaining weather forecasts, name it WeatherForecast (but don’t postfix it with 'Provider').

After selecting the Add button, five classes in five different files are generated for you. They are XXX, XXXProviderBase, SqlXXXProvider, XXXProviderCollection and XXXSection (where XXX is the concept name of your provider, of course ;-)). The generated code will contain TODO comment tags, so you know exactly where to add your custom functionality.

The XXXProviderBase functions as base class for all concrete provider implementations. A provider for the desired concept that is created must inherit from XXXProviderBase. You will have to define some abstract or virtual methods that concrete implementations can implement or overwrite. For the WeatherForecastProviderBase, there could be an abstract GetForecast() method. Optionally you will need to write some logic to extract some values from the configuration that is common to all concrete implementations. This must be done in the Initialize method.

The XXX is the façade that consumers of your provider will use. It is a static class that is responsible for creating concrete providers based on the definitions in the configuration file. The class will usually contain the same methods as the XXXProviderBase and will delegate those calls to the underlying provider implementation. Implementing this is usually very basic. An example is given in the code generated by the template.

The SqlXXXProvider is a concrete example of a provider, but it can be removed if you don’t intend to implement a concrete provider that communicates with a SQL Server database. As an example how to load values from the configuration file, this provider collects a connection string from config and loads it into the ConnectionString property.

The two remaining classes XXXProviderCollection and XXXSection are needed by the provider model to generate providers and values from the configuration file. These files can be extended, but I normally leave them as they are.

The template generates example XML that you can copy-paste to your configuration file. For the WeatherForecast provider, the XML looks as follows:

<section name="WeatherForecast"
type="Providers.WeatherForecastSection, Providers"
allowDefinition="MachineToApplication" />
<WeatherForecast defaultProvider="SqlWeatherForecastProvider">
type="Providers.SqlWeatherForecastProvider, Providers"
description="SQL Weather provider." />

Within the <WeatherForecast> section, multiple concrete providers can be defined. What I like about the provider model is that it is flexible, extendable and very easy to use. You can deploy the assembly with your provider model and include a few concrete implementations, like a SqlXXXProvider as generated or an XmlXXXProvider, and optionally some controls or components that use your provider model. Someone else can then use your provider model and one of your concrete providers, or decide to plug in his own implementation. This basically comes down to creating a class that inherits from XXXProviderBase and registering it in the <providers> section of the configuration file, as shown in the above XML snippet.

<UPDATE 2009-05-21>
Note that the template creates a dependency on the System.Web assembly. The reason this happens is because the static XXX façade uses the System.Web.Configuration.ProvidersHelper to instantiate new providers from configuration. This normally isn't such a problem, even if your provider isn't ASP.NET specific, but I can think of two reasons not to want this. The first is performance. Loading System.Web isn't free. I expressed the other reason why not to use the ProvidersHelper here on the Microsoft feedback site. You can replace the call to ProvidersHelper.InstantiateProviders from within the XXX façade to your own implementation and look it up with Reflector. A basically did the same in Cuttingedge.Logging, a logging framework based on this provider template. Look at the implementation of the Logger class to see how I did this.

The provider model is a very useful model and this template can give you a kick-start when rolling your own.

Happy coding!

- .NET General, ASP.NET, C#, Visual Studio - two comments / No trackbacks - §

The code samples on my weblog are colorized using javascript, but you disabled javascript (for my website) on your browser. If you're interested in viewing the posted code snippets in color, please enable javascript.

two comments:

its kool man ... and prety help full
asfand - 18 09 08 - 10:05

aleem - 16 04 12 - 13:59