Custom Business Objects

Provider Model

The Provider Model is a design pattern that is used in the DotNetNuke architecture to allow core functionality to be replaced without modifying core code. The introduction of the Provider Model started with Microsoft in its need to provide a simple, extensible API in .NET. The Provider Model was formalized in ASP.NET 2.0 as a best-practice design pattern. The purpose of the Provider Model is to provide a welldocumented, easy-to-understand API that has the benefits of simplicity and the power of extensibility.

To provide both simplicity and extensibility, the API is separated from the implementation of the API. A provider is a contract between an API and the business logic that establishes the functionality that the implementation of the API must provide. When a method in the API is called, it is the implementation of the API that fulfills the request. Simply put, the API doesn't care how the job is done, as long as it is done. If there is one useful concept garnered from this section, let it be this oversimplification of the purpose of the Provider Model:

Note 

Build things so they do not depend on the details of other things.

This fundamental design concept was recognized well before the Provider Model came to fruition, but it truly speaks to what the Provider Model brings to developers. The API in the Provider Model does not depend on the details of the implementation of the API. Therefore, the implementation of the API can be changed easily, and the API itself is unaffected due to the abstraction.

Provider Model Usage

There are several areas in DotNetNuke that use the Provider Model:

• Data Provider

• Scheduling Provider

• Logging Provider

• HTML Editor Provider

• Search Provider

• Friendly URL Provider

The first implementation of the Provider Model in DotNetNuke was the Data Provider. DotNetNuke originally supported only Microsoft SQL Server. The core of the portal was tightly coupled with the data tier. There were many requests from the community to extend DotNetNuke to support other data stores. We needed a way to support a diverse array of data stores while maintaining a simple Data Access Layer and allowing for extensibility. That's when the concept of the Provider Model was first introduced into DotNetNuke.

Figure 7-1 shows that the Data Provider API is not dependent on a tightly coupled implementation of the API. Instead, the Data Provider API doesn't even know what kind of data store is being used until you configure an XML setting in the web.config file. Other than the settings in web.config, the only other requirement of the Data Provider API is that the implementation of the API must fulfill its contract by providing the necessary functionality defined in the base class. For example, all methods marked with MustOverride in the Data Provider API must be overridden in the implementation of the API.

Figure 7-1

Provider Configuration

The Provider API has to be configured to work with the implementation of the API. The API needs to be configured to know which type and assembly to use for the implementation of the API. As mentioned in the previous section, this is handled in the web.config file.

The configuration settings are in XML in the web.config file. There is no standard for naming conventions or the structure of the configuration settings in the Provider Model in general. However, DotNetNuke has followed a consistent pattern in each Provider Model API and the associated configuration settings.

Each API may have different requirements for configuration settings. For example, the Data Provider API needs a connection string defined in its configuration settings. The XML Logging Provider needs its log configuration file location defined in its configuration settings. So each API has configuration settings that are specific to it.

The DotNetNuke core providers store the Provider Model API configuration settings in web.config under the /configuration/dotnetnuke node. When a Provider Model API is first instantiated, it collects these settings, which enable it to use the specified implementation of the API. The configuration settings are then cached so that in subsequent requests, the configuration settings are retrieved more quickly. Listing 7-1 shows a section of the web.config file that contains the Data Provider API's configuration settings.

Listing 7-1: Data Provider Configuration Settings

 <data defaultProvider="SqlDataProvider">       <providers>             <clear />             <add name="SqlDataProvider"             type="DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider"             connectionStringName="SiteSqlServer"             upgradeConnectionString=""             providerPath="~\Providers\DataProviders\SqlDataProvider\"             objectQualifier=""             templateFile="DotNetNuke_template.mdf"             databaseOwner="dbo" />       </providers> </data> 

The Provider Model has brought great value to DotNetNuke in the way that it allows for functionality to be replaced without modifying the core code. In DotNetNuke, as in most open-source applications, the core code should not be modified by its consumers if at all possible. The Provider Model helps enforce this fundamental standard of open-source application development. It also provides a new level of abstraction between the Data Access Layer and the data store.