Detailed analysis of ASP. NET 2.0 Provider Model

This articleArticleIt is more based on the translation of this article, which integrates your understanding of the article, it is also a reading note. Hope that more people can understand and master this useful mode and apply it to yourProgram.

. Why we need it

I always think that the first thing I should know is the cause of this problem. Only by figuring out the ins and outs of things can you have a clear understanding of the current situation. This is a big premise! As mentioned in the article, fixed choices, fixed internal behaviors, and fixed data schema are common problems we encounter when using some class library APIs. For example, "fixed choices" and Asp.net sessions support a working mode named out-of-process, meaning that you can store the State data of your application outside the working process of Asp.net, there are only two options, either stored in Asp.net's proprietary state server or in SQL Server. Yes, as you may think, there is a problem here. What if I want to use MySQL for storage?
For example, "fixed internal behaviors" is still the out-of-process of Asp.net session. Suppose we want to retrieve the status data of the SQL server stored outside the process, at this time, the API behavior provided by Asp.net is fixed. We can only retrieve all the stored status data at one time or not at all. Imagine if the total size of the stored data is 50 MB, but all we need is 50 kb... you get the picture!
There are many other similar examples. In fact, the following is an overview:

 
"The inability to change core behavior or functionality of published APIs ."

There is no good way to change the existing behaviors of published APIs!
 

Solution: You may say it doesn't matter if I write my own "session state". This is good, but it may also cause many problems, the most obvious thing is that developers need to abandon the APIS they are already familiar with and instead learn your proprietary APIs. This is the cost and the efficiency should be reduced. So...

 
"What we really want is a way for everyone to get the benefits of well-known ented and familiar programming interfaces, such as session state, but the ability to completely control the internal business logic layer (BLL) and data access layer (DAL) of these Apis"

What we really want is to have complete control over the internal logic of these Apis while continuing to use our existing experience in well-regulated and well-documented APIs.
 

. The provider Design Pattern

In essence, the provider mode is very simple. It is called "provider" because it provides the actual behavior logic of the Upper-layer API. As mentioned in the article, membership in Asp.net has a static method called validateuser (), but the membership class itself does not contain any business logic about this method. On the contrary, when validateuser is called, it simply transfers the call to the configured provider, which is responsible for implementing the specific logic of the validateuser method.

"It is the responsibility of the provider class to contain the implementation for that method, calling whatever business logic layer (BLL) or data access layer (DAL) is necessary ."
 

In fact, I personally think that the introduction to the provider mode will end here. This is because we have fully understood the cause of a model and its detailed definition. The rest is just how to implement such a model, students with strong abilities can have their own ideas in their minds and then start to implement them. (Of course, it may take a lot of iterations to come up with a decent provider mode ). Because of the differences in platforms, the ultimate implementation of a model with different restrictions (including language and Framework) may be different, but the inherent nature must be the same, so let's take a look at the provider mode in Asp.net.

. Provider in Asp.net

in fact, we can see from another article that, the provider mode in Asp.net seems to be more specific to the provider of the state storage service. In short, Asp.net 2.0 provides many services, including the well-known membership service, site Maps service, profile service, and other services, one common feature of these services is the persistence storage of some State data during the running process of the application. Our provider mode is just to show its talents here. APIS of the Upper-layer service do not directly interact with persistent media in the lower-layer state, but are connected through providers. As shown in:
of course, I personally think, the provider mode not only decouples the interaction between upper-layer services and underlying physical storage media, but also applies providers to such applications on a large scale in Asp.net.

   " 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. because always Ally all ASP. NET 2.0 state-management services are provider-based, storing session state or membership state in an Oracle database rather than a Microsoft SQL Server database is as simple as plugging in Oracle session state and membership providers. code outside the provider layer needn't be modified, and a simple configuration change, accomplished declaratively through web. config, connects the relevant services to the Oracle providers. "
    

All providers in Asp.net directly or indirectly inherit from a base class named providerbase (located under the system. configuration. provider namespace ). Privoderbase is the specific applicationproviderbase, such as membershipproviderbase. Simply put, this base class is an intermediate class connecting the underlying base class and the more specific provider at the upper layer. Then let's look at the actual provider, such as sqlservermemberhipproviderbase or oraclemembershipproviderbase. The following figure gives a clearer description:

At the same time, we must define a configuration information section in the configuration file to load our provider at runtime, like this:

 1   <  Configuration  >  2   <  Forums  >  3  <  Forums  Defaultprovider  = "Sqlforumsprovider"   Defaultlanguage  = "En-en"   >  5  <  Providers  >  6  <  Clear  />  7  <  Add  Name  = "Sqlforumsprovider"   Type  = "Aspnetforums. Data. sqldataprovider,  Aspnetforums. sqldataprovider"   10  Connectionstring  = "[Connection string]"  11  Databaseowner  = "DBO"  />  13   <  Add  Name  = "Accessforumsprovider"   Type  = "Aspnetforums. Data. accessdataprovider,  Aspnetforums. accessdataprovider"   16  Filelocation  =  "~ \ Data \ accessdataprovider \ aspnetforums. mdb"  />  19  </ Providers  >  20  </  Forums  >  21   </  Forums  >  22   </  Configuration  > 

Of course, provider alone is not enough. In retrospect, the provider we mentioned above is designed to provide specific behavior logic for upper-layer APIs, so we still lack an upper-layer API, these are the application interfaces that are finally exposed to users, such as the membership class and sessionstate class.

. Pattern in real

Let's take a simple look at what we have in our hands:
1). A service class that encapsulates a series of released API interfaces. They represent the services that an application can provide, such as membership;
2). A providerbase base class that encapsulates the attributes and actions common to all providers;
3 ). A class inherited from providerbase, which is usually specific to our applications. The function provided in it is almost an image of the servcice class. We call it the applicationproviderbase class, such as membershipproviderbase;
4). A Class inherited from applicationproviderbase. It is our real and specific provider, such as sqlservermembershipprovider;
The above components are essential to form the provider mode in Asp.net. Let's take a look at how they work collaboratively at runtime. For more details about this part, refer to this article. Take the membership service as an example. Our membership service provides many convenient functions for applications to manage user authentication data in a unified manner, such as creating a user (createuser) or verifying a user (validateuser. Now the application calls the membership. validateuser () method. The internal method may be like this:

  1   Public   static   bool  validate ( string  username,  string   password)   2  {  3  membershipprovider provider =  membershipprovider. instance ();   4   return   provider. validate (username, password);   5 }

Then the instance () method will be called, and the internal implementation may be implemented by a tool class called providerhelper (it is in the system. Web. Configuration namespace ). It reads the required information from the configuration file and instantiates a specific provider class based on the information. Each provider class can choose to overload the initialize method in the base class to provide its own instantiation implementation. After a specific provider instance is obtained, for example, sqlservermembershipprovider, our call is passed to this actual provider, where the logical implementation specific to the application is provided, for example, the validate method connects to the SQL Server database to obtain the stored user name and password, and compares it with the parameters passed in by the method to determine whether the currently verified user is a legal user.

Do you have any feelings about the provider mode?

Here are some reference documents that I think are better. If you are interested, please read them to learn more about the provider mode:

Http://msdn.microsoft.com/en-us/library/aa479030.aspxASP. NET 2.0: Introduction to the Provider Model

Http://msdn.microsoft.com/en-us/library/ms972319Provider Model Design Pattern and Specification