The Provider Design Pattern

The provider design pattern exists to allow you to extend features of ASP.NET by swapping out the standard ASP.NET providers with yours. A provider is both a Data Abstraction Layer and a Business Logic Layer class that you create and plug into ASP.NET. When features such as Personalization are used, instead of calling one of the ASP.NET providers to retrieve or store user data, your class can be called, and within that class you can make decisions on how to operate on and store that data. Developers continue using the familiar APIs supported by ASP.NET, but it's your code that is running.

The beauty of the provider design is that it allows developers to learn to program to a well-known API, while internally the API can behave differently (e.g., SQL versus Oracle data stores).

Providers are based on the common object-oriented principles of abstraction. A class implements an interface and applications can then depend on the interface instead of directly on the class. Internally the functionality can be completely different from class to class, but the object model is the same. For example, ASP.NET Personalization supports a name /value table for storing personalization data. If you wish to use your own data structure, as shown later in this chapter, you would author a provider.

The provider design pattern is comprised of the following:

• Configuration

• Implementation of the IProvider interface

• Implementation of the specific feature interface

Configuration

All ASP.NET features that implement the provider model require a <configuration/> section where providers are added. Additionally the feature requires a defaultProvider attribute to identify which provider is the default.

Listing 7.11 demonstrates how this is used in the <personalization/> section.

Listing 7.11 Configuring a Default Personalization Provider

 <configuration>   <system.web>     <personalization defaultProvider="AspNetAccessProvider">       <providers>         <add name="AspNetAccessProvider"              type="System.Web.Personalization.                    AccessPersonalizationProvider,                    System.Web,                    Version=1.2.3400.0,                    Culture=neutral,                    PublicKeyToken=b03f5f7f11d50a3a"              connectionStringName="AccessFileName"              applicationName="/"              description="Stores and retrieves personalization                           data from the local Microsoft Access                           database file" />         <add name="AspNetSqlProvider"              type="System.Web.Personalization.                    SqlPersonalizationProvider,                    System.Web,                    Version=1.2.3400.0, Culture=neutral,                    PublicKeyToken=b03f5f7f11d50a3a"              connectionStringName="LocalSqlServer"              applicationName="/"              description="Stores and retrieves personalization                           data from the local Microsoft                           SQL Server database" />       </providers>     </personalization>   <system.web> </configuration> 

Implementers of providers should have a defaultProvider attribute on the main <configuration> section. If a default provider is not specified, the first item in the collection is considered the default.

Managing Providers in Configuration

The <providers/> configuration section contains one or more <add> , <remove> , or <clear> elements. The following rules apply when processing these elements.

• It is not an error to declare an empty <providers/> element.

• Providers inherit items from parent configuration <add> statements.

• It is an error to redefine an item using <add> if the item already exists or is inherited.

• It is an error to remove a nonexistent item.

• It is not an error to add, remove, and then add the same item again.

• It is not an error to add, clear, and then add the same item again.

• <clear> removes all inherited items and items previously defined (e.g., an <add> declared before a <clear> is removed, but an <add> declared after a <clear> is not removed).

Table 7.3. Provider Attributes

Element	Description
<add>	Adds a data provider. Supports the following attributes: name : The friendly name of the provider. type : A class that implements the required provider interface. The value is a fully qualified reference to an assembly. Other name/value pairs : Additional name/value pairs may be present, such as connectionName for the default ASP.NET SQL Personalization Provider implementation. All name/value pairs are the responsibility of the provider to understand.
<remove>	Removes a named data provider. Supports the following attribute: name : The friendly name of the provider to remove.
<clear />	Removes all inherited providers

Table 7.3 lists the elements of <provider/> .

Implementation of the IProvider Interface

All providers are required to implement the IProvider interface (see Listing 7.12).

Listing 7.12 The IProvider Interface

 namespace System.Configuration.Providers {   interface IProvider {     // Methods     void Initialize(string name, NameValueCollection config);     // Properties     string Name { get; }   } } 

The IProvider interface is used by ASP.NET to enforce a standard way to initialize providers. The Initialize() method should set the name of the provider from the name attribute within the configuration file, and the config NameValueCollection is a collection of attributes and values specified in the <add/> of the provider. This collection would contain any additional properties needed by the provider, such as a connection string for connecting to the database.

Table 7.4. Feature Interfaces

Feature	Interface
Membership	System.Web.Security.IMembershipProvider
RoleManager	System.Web.Security.IRoleProvider
Personalization	System.Configuration.Settings.ISettingsProvider
Page Personalization	System.Web.Personalization.IUrlPersonalization Provider
Site Map	System.Web.ISiteMapProvider
Site Counters	System.Web.ISiteCountersProvider
Health Monitoring	System.Web.Management.IWebEventProvider

Implementation of the Specific Feature Interface

All ASP.NET features that support providers will also support specific feature interfaces. Table 7.4 lists features as well as their interfaces.

The provider class implements the feature interface as well as IProvider .