Experience the elegance of. net2.0 (4): Provider, policy, control reversal, and dependency Injection

In the configuration file of ASP.net 2.0, the shadow of the Provider is often seen, for example, XmlSiteMapProvider in StarterKit and SqlMembershipProvider implied when Login Controls is used. So many providers, I guess they must have a common father! After reading the information, I did not expect that their father was ProviderBase.

[The three vertices in the figure represent the name of the direct parent class]

Taking Membership as an example, let's take a look at how so many providers are used by the system and what benefits they will bring to us.

LoginControls (including logon, User Creation, password modification, and other controls) are server controls that use MembershipAPI to perform relevant operations. MembershipAPI is a seal class (System. web. security. membership class), which defines many static methods, including CreateUser and DeleteUser, but does not provide specific implementation, but uses the services provided by MembershipProvider. MembershipProvider is an abstract class that defines methods such as CreateUser and DeleteUser. SqlMembershipProvider is an implementation of this class. It can persistently store Membership data to SQL Server 2005.

1. Strategy

An atypical strategy is used here ). In a typical policy mode, the Provider should be injected through the constructor. In this case, Membership is a static class, and its Provider and ProviderCollection are both read-only attributes, therefore, I guess the Provider is not injected by other classes, but obtained by the Provider itself through the application context. The role of the Policy mode is to convert the dependency of MembershipAPI on a specific Provider (such as SqlMembershipProvider) into a dependency on the abstract class MembershipProvider + SqlMembershipProvider on MembershipProvider, so as to comply with the open and closed principle (OCP ). This ensures system flexibility and efficiency.

2. IoC

One of the advantages of the policy pattern applied here is that it achieves control inversion (IoC ). Generally, we design a layered application from the bottom layer to the top layer. The upper layer components use the services provided by the lower layer and directly rely on the components of the lower layer. The disadvantage of this is that it is difficult to modify the underlying components, because any modifications (such as the function or name of the modification method) may cause the upper-layer application to crash. After the policy mode is used, we place the abstract classes of MembershipAPI and MembershipProvider on the same layer (upper layer). The underlying SqlMembershipProvider depends on the previous layer (implementing the abstract methods in MembershipProvider ). Obviously, the dependency of the Upper-layer component on the lower-layer component is converted into the dependency of the lower-layer component on the upper-layer component. This is the inversion of control. The advantage is that the plug-and-play function is provided-the Provider is pluggable, and the Provider is responsible for all system crashes caused by the Provider.

3. Dependency Injection

We can implement our own MembershipProvider, for example, OracleMembershipProvider-use Oracle to store Membership and Profile data-as long as we inherit some of the methods of the MembershipProvider class and override it. So how is the OracleMembershipProvider we wrote or the SqlMembershipProvider that comes with the system used by MembershipAPI? Here is an important concept-Dependency Injection ). Dependency injection refers to injecting the components that the application depends on to the application at runtime. Dependency injection generally uses reflection technology.

Dependency injection is usually divided into three forms:

Constructor injection: component injection through Constructor
Set Value injection: sets the attribute value to inject components.
Interface injection: Get the implementation of the specified interface from the container

The injection process is generally completed by an IoC container (such as Spring) and is especially suitable for containers. It is hard to say that MembershipAPI uses a typical dependency injection method. We can say that we only use the reflection factory. Here, reflection alone is sufficient, and complex object assembly processes are not required.

Without considering the internal implementation process, we only need to copy our implementation to the Bin directory and add the following nodes in the system. Web section of the web. Config file:

<Membership>
<Providers>
<Clear/>
<Add name = "OracleMembershipProvider" type = "Oracle. OracleMembershipProvider"/>
</Providers>
</Membership>

The type field defines the full name (including the namespace) of the custom Provider ).