ASP. net2.0 Provider Model (I)-principles, models, and analysis

Summary

The term "provider" is used to study ASP. net2.0's friends are familiar with ASP. new features such as net2.0 membership (membership management), sitemappath (site map), and personalization are built based on the provider model. For this reason, understanding and familiarity with the provider model directly affects the use of some new ASP. net2.0 features. In addition, there are very few materials (especially Chinese) about the provider model. In the spirit of sharing "everyone for me, everyone for me, I decided to share with you my experiences in using the Provider Model, hoping to serve as an ASP. useful references for net2.0 beginners. You are also welcome to participate in the guidance and addendum for "High hand.

This series of articles will be divided into three parts: Asp. net2.0 Provider Model (I)-principles, models, and analysis focuses on the principle and structure of the provider model. net2.0 Provider Model (medium)-templates and examples focuses on implementation. The provider model template is used as an example to explain the reference implementation of the provider model. The next article ASP. net2.0 Provider Model (bottom)-Asp. net2.0 membership management will be applied to ASP. the new features (membership management) built in net2.0 are oriented to the provider model to analyze their composition and their relationship with the "Logon control.

 

Main Content

I. What is the provider model?

L principles and Models

Ii. Composition of the Provider Model

L model Composition

L asp. net2.0 Provider Model Composition

L relationship between Provider Model and Software Architecture

 

Body

 

Overview

In ASP. before net2.0 was launched, the provider model should be relatively "low-key", but with ASP. with the popularity of net2.0, the provider model becomes the key to flexible use of new features such as membership (membership management), sitemappath (site map), and personalization. If the provider model is ignored, ASP. net2.0 you know is incomplete.

Many friends who are new to ASP. net2.0 may have some questions: why does the app_data directory on the Site Automatically generate the aspnetdb. MDF database? Why does the logon control depend on the sqlserver2005express database? Would you like to replace Data Storage with sqlserver2000, orcale, access, or even MySQL? To use the logon control (or membership), do you need to use the automatically generated database table (prefix table with "ASPnet _") to store data ?...... In fact, you can find the answer from the provider model.

As the first article of this series, this article consists of two parts: the first part describes what is the Provider Model and why it is used (what problems it solves ); the second part describes the composition (participants) of the provider model and their respective functions.

 

I,ProviderWhat is a model?

In fact, the provider model is a design model. When talking about the design pattern, we can understand the "inner" of the provider model from the concept of the pattern ". First, you need to understand that the provider model is not a specific product but a design concept. It is not unique to Microsoft, not implemented in the. NET environment. Secondly, the provider model is not exclusive to ASP. net2.0, nor is it a new design pattern designed to cater to the emergence of ASP. net2.0. Only. NET Framework 2.0 has built-in support for this design model (discussed later), which is easier to use. In fact, the provider model can be implemented in framework1.1 or even Java.

 

Modes and principles

Since the Provider Model is a design model, let's discuss it from the perspective of the model. We all know that the design pattern is defined as "a description of the classes and objects used to solve general design problems in specific scenarios ." (Gof ). The first step is to clarify the design issues (application scenarios) it solves. The second step is to clarify the participants and their respective functions (discussed in the second section ).

So what design issues have the provider model solved? In a word, the Provider Model removes the dependency of Customer Code on specific storage, and decouples application code from the specific data access logic. The applications designed with this model will meet the OCP design principles (open to extensions and closed to code modifications), that is, using the Provider Model to develop the system, it will provide flexible scalability for specific data storage. Specifically, we do not need to consider whether the final data storage uses sqlserver, orcale, access, or even XML for system development. We only need to select one of the specific data storage (usually sqlserver) as the default implementation; when the demand changes (the customer requires the database management system to use orcale ), only two steps are required. One is to perform specific implementation classes based on the orcale database, and the other is to modify the configuration. For the Code Compiled by the system, you do not need to modify and compile it, the system still works as usual. (The specific implementation will be discussed in the next article)

 

II,ProviderModel Composition

After having a preliminary understanding of the provider model, we will start to analyze it in detail. As mentioned above, the provider model is a design concept. Therefore, this section will first perform a conceptual analysis on the model, and then combine it with ASP. net2.0 provides a detailed internal analysis of the provider model, and finally discusses the relationship between the Provider Model and the software architecture.

 

ProviderModel composition (Conceptual Model)

The provider model is analyzed from the conceptual perspective. The participants and their relationships can be summarized as follows:

 

 

It consists of four participants:

1.ProviderAbstraction-- This object is mainly responsible for planning the data access logic (abstraction ). It can be implemented as an abstract class or interface. The so-called planning is to customize the method signature for the data access method that the module needs to execute (including all overloading), that is, to design the return values, names, and parameters of the data operation methods related to all modules, but it is not implemented.

2.ProviderImplementation-- This object has two main functions. The first and most important function is to implement (rewrite) Provider abstract planning methods for different data storage. The second is to define, read, and process data, attributes that can be configured by the user (such as connection strings ).

3.ProviderService API-- This object is the programming interface of the Upper-layer application code. It is internally associated with the provider abstraction and provides an upper-layer calling interface for the methods planned in the provider abstraction. This satisfies the OCP principle and relies on abstraction, so it also meets the dip principle. When you need to modify the implementation class objects loaded by the provider abstraction, you only need to modify the configuration file, and the upper-layer applications and even the Provider Service APIs do not need to change any code and re-release it. In addition, because abstract (Interface) programming is used, this object must solve the problem of object loading. (The next article provides a simple implementation method)

4.ProviderConfiguration-- Through configuration management, users can choose to abstract the specific provider implementation object in the Provider Service API.

 

ASP. net2.0 providerModel Composition

As mentioned above, ASP. net2.0 has built-in support for the provider model, which provides a convenient implementation method. The namespace system. configuration. provider is added to 2.0.

Combined with the conceptual model of the previous section for analysis, the providerbase abstract class in the system. configuration. provider namespace provides a uniform "Specification" for the implementation of all provider models ". That is to say, to implement the built-in supported Provider Model in 2.0, the key is that the provider abstraction must inherit from the providerbase abstract class.

Careful friends should notice that the namespace in which providerbase is located is related to configuration. Is it related to configuration? 2.0 solves the specific object Loading Problem of the provider abstraction in the Provider Service API through configuration management. According to msdn, the definition of providerbase is actually very simple, and there are only a few key members:

L name attribute: name of the provider instance used in the Configuration Management Code.

L description attribute: Brief description.

L initialize method: This method is very important. The provider implements reading and processing of configuration data by rewriting it. It should be emphasized that although the provider abstraction inherits from providerbase, the initialize method is generally rewritten in the provider implementation.

In addition. configuration. there are two classes in the provider namespace: first, providercollection is the set of derived classes of providerbase, which is actually the set of specific provider implementations added in the configuration file; second, providerexception is a provider configuration exception. This class is mainly used to override the initialize method of providerbase. The initialize method is described above to read and process the attributes of the specific provider implementation configured by the user. The core idea is: in the web. in config, read and process the properties implemented by the specific provider, and then remove the processed properties from the provider configuration object, finally, judge whether there are still unprocessed properties in the property set of the configuration object. If yes, it indicates that the user's configuration is incorrect (the attribute we do not know is configured ), in this case, a providerexception is thrown. (For more information, see section 3 ).

After learning about the 2.0provider model, we can see that the model diagram of 2.0 provider only requires a few changes on the base of the provider conceptual model diagram described above. The key is that the first part (provider abstraction) in the figure inherits from providerbase. Providerbase is also the base class of the new features such as membershipprovider, roleprovider, and sitemapprovider. (Membership management will be discussed in detail in the next part of this series)

 

ProviderRelationship between model and Software Architecture

In order to better understand and use the Provider Model, the last part of this section will discuss the relationship between the Provider Model and the software architecture.

The Provider Model concept diagram in the previous section shows that the provider model is located at the data access layer in the software architecture. We have learned about the data access layer technology and ADO. net, daab2.0, and enterprise database daab. What is the relationship between them? See (this figure mainly emphasizes the hierarchical relationship from bottom to top ):

 

The relationship between the Provider Model and the software architecture is summarized as follows:

1. The core participants of the provider model are located at the data access layer.

2. In the Provider Model, objects related to data access directly depend on the provider implementation.

3. The provider can directly use the ADO. Net object to access data, or use daab as the enterprise database daab.

4. The Provider Model is closer to the business logic layer than the enterprise database daab.