The provider model for deep asp.net 2.0

In this article, we will examine the provider model in detail and analyze how it can be applied to ASP.net 2.0 development, including API implementations, provider model benefits, ASP.net 2.0 provider models, and supplemental information.

First, the introduction

As early as 2001, I started to develop a asp.net online messaging board application webforums.net. The goal is to create a asp.net message board system that can easily be plugged into an existing Web site. One of the special challenges in building such an end-to-end application is to provide customers with a way to integrate it into their own systems. For example, an online forum obviously needs to use some kind of data store to store user information, forums, and postback information, but it is best not to lock customers into a particular data store. In other words, you should not say, "My application must use Microsoft SQL Server 2000", so how can a client using Oracle or access use your software?

Another problem that integrates into the customer's existing data is that all online forum sites provide user accounts and a way to create new accounts. Typically, this is modeled as a forum architecture (in the form of the Users table in a database). However, customers are likely to already have their own database tables with thousands of user accounts. Alternatively, a customer might want to use the forum in an intranet setting and would like to use the Active Directory instead of some kind of database table to authenticate and store user information. So, when a forum software system creates a users database table and says to its customers, "This is how you store users," Customers who already have existing infrastructure and user data are likely to alienate such software.

Therefore, when you use a "stiff" API to build a system, there are special challenges. A "stiff" API does not provide a way to customize logic but to Hard-code implementation details (for example, you have to use SQL Server as your backend data store, and in this database there is a users table, where all the user information will be stored). However, by using the provider design pattern, you can easily break this "stiff" sex. With the help of provider design patterns, system architects only need to define APIs, and programming functions are provided by the system. For an online forum application, this may include a users class with methods such as Authenticate (Username,password) and getuserdetails (username).

The good of the provider model is that the customer implementation can specify a custom class that the system should use. This custom class must implement a well-defined API for the system, but it allows seamless insertion of any custom implementation. That is, once the API is defined, the system's implementation can create a default concrete implementation that uses SQL Server and a user table-most customers can use it without any modification. Customers who have custom needs (who want to use Oracle or otherwise store user data) can create their own classes that provide the necessary functionality and plug them into the customer's system.

In fact, the provider design pattern is applied to the entire ASP.net 2.0 implementation. Of course, there are also tutorials on how to use this feature in ASP.net 1.x applications.

In this article, we will explore the provider model in detail and analyze how to apply it to ASP.net 2.0 development.

Ii. breaking the "stiff" API implementation

In my early webforums.net development, I realized that this "stiff" API implementation would be a problem. One of my software design goals is to be as flexible and customizable as possible, and to make SQL Server available to users, and my user data model implementations should look just a little restrictive at best. To overcome these problems, I built a system that contains the following two parts:

1. A set of abstract base classes that define the core functions of the system;

2. Ability to dynamically load an extended abstract base class at run time. Specifically, the code is responsible for checking the Web.config file that contains a section that gives the fully qualified name of the class to use.

With this architecture, I can define the functionality of the system through a series of abstract base classes, and use the SQL Server 2000 and users tables to provide concrete implementations of these classes. Customers who meet this configuration can just use the application, and everything will work well without the need for them to write a single line of code. However, developers who need customization can be implemented by creating their own classes that derive from the appropriate abstract base class. By simply putting the assembly in the application's/bin directory and updating the Web.config file, they can let the system use the new class. Specifically, the Webforums.net release comes with an abstract base class Dataprovider, which clearly enumerates all the methods in the system, similar to the following:

public abstract class DataProvider
{
public abstract bool AuthenticateUser(string username，string password);
public abstract User GetUserInfo(string username);
...
public static DataProvider Instance()
{
...
}
}