The provider model for deep asp.net 2.0 __.net

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", because of this, how can the 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

{

publicabstract bool Authenticateuser (stringusername,string password);

Public abstract User GetUserInfo (string username);

...

public static Dataprovider Instance ()

{

...

}

}

The Authenticateuser (Username,password) and GetUserInfo (username) methods are representative of two methods in many of the methods defined by the system. The static instance () method is the main implementation of the Dataprovider class, and it contains code that checks for Web.config files that represent webforums.net configuration information that indicates the full name of the class to be used by the system. The method then uses reflection (and buffering) to create an instance of the class and return it to the system.

The Webforums.net release also comes with a Sqldataprovider class derived from the Dataprovider base class, which provides a concrete implementation of the classification method. For example, all Sqldataprovider methods can manipulate data stored in a SQL Server 2000 database, and user-related methods can work with a predefined users database table. A customer who wants to change the backend functionality can create his own derived Dataprovider class, which can be displayed in Web.config files (indicating that their custom class should be used). For example, Web.config in Webforums.net may include the following:

By default, this setting information refers to the Sqldataprovider class that is issued with Webforums.net. However, if a customer creates his own API implementation, he can provide details of his class, and the system will automatically start using his implementation to create the default implementation.

With this architecture, page developers using Webforums.net can authenticate a user using the code shown below:

if (Dataprovider.instance (). Authenticateuser (Username,password))

User is authenticated

Else

User name/password is not valid.

When the Dataprovider.instance () method is invoked, the above configuration file is checked and an instance of the appropriate class is returned. This will be the default Sqldataprovider class if the customer has not yet created their own implementation, and if they have already implemented it will be their own class. Once the Dataprovider.instance () method returns an appropriate provider instance, we can simply invoke the members of the API (in this case, the Authenticateuser ()).

Webforums.net provider Model-an early prototype

Andy's provider model has some drawbacks relative to the provider model suggested by Microsoft. On the one hand, a single abstract base class is provided in Webforums.net, and all API definitions are clustered in this class. The downside is that if a customer only wants to customize a small part of the system, such as how the user information is stored, then he must provide the implementation of all the methods in the system. A better scenario is to create an abstract base class for each logical entity in the system. For example, for an online messaging board application, it may require some classes, such as Usersprovider,forumsprovider,postsprovider, and so on. However, there is a trade-off between the number of providers you provide to a customer. More providers allow more granular system customization, but also increase the number of required configuration tags accordingly.

In addition, I have shown further improvements to the WEBFORUMS.NET provider model implementation code to make it more similar to the code used by Microsoft in asp.net2.0. I think Andy's idea should be a pioneer in the provider model, although Microsoft's provider model is clearer and stronger.

On the one hand, Webforums.net was acquired by Microsoft in March 2002, and on the other hand, Rob Howard and others added a lot of new features to the system and released it freely in the ASP.net forum. Today Rob and his team have turned the ASP.net forum into a community server (it simply integrates blogs, forums, galleries, list servers, news readers, etc.). Today, the concepts and implementations that Andy created are widely used in asp.net forums and community servers, and even in many core ASP.net 2.0 components.

Third, provider model benefits

The provider model offers many advantages. First, there is a clear separation between the code and the backend implementation. Regardless of whether a user's code is for a SQL Server 2000 database's users table or an Active Directory store, the code looks the same from the page developer's view:

Dataprovider.instance (). Authenticateuser (Username,password);

Also, the backend implementation changes are transparent.

Because the system Architect is encouraged to create a default implementation, so the provider model provides the best combination of the two worlds: if the default implementation is already satisfactory, the system works as expected, and for those who need to customize the system, they don't have to interfere with existing code or programming logic. This design pattern also makes prototyping and sensitive development much easier. For example, in the early system usage phase, it may be easier to use only the default implementation. However, in the future you may need to customize some aspects to integrate the work with your company's existing systems. At this point, you can implement the customization required by the provider model. This means that you do not need to change your early work to reflect changes in the backend implementation.

Like many good design models, the provider model also provides a separation of responsibilities among developers. In this way, some developers can work with their proficient system APIs, while others can focus on backend implementation and custom task development, and the two groups can work on the same system without interfering with each other. And if the system they use is an industrial standard (such as ASP.net 2.0), then the skills in both types of tasks can be easily ported to future work.

Four, ASP.net 2.0 provider models

ASP.NET2.0 uses the provider model in all of its schemas. For example, many of its subsystems-members, site navigation, personalization, and so on-utilize the provider model technology. Also, each subsystem provides a default implementation, but it also enables customers to tailor their functionality to meet their own needs. For example, the site Navigation section of ASP.net 2.0 allows a page developer to define the navigable structure of their site. The data can then be used by a variety of Web controls to display site maps, tree views, or menus-they can highlight the site's navigation and/or display the user's site location. In addition to navigation-related Web controls, the site navigation API provides a set of methods for interacting with site navigation information.

By default, navigable information for a site must be encoded in a properly formatted XML file. This way of storing data is that the default site navigation is hard-coded. However, Asp.net2.0 's provider model makes it easier for you to use your own data store to achieve site navigation. For example, in a project that I am currently developing, a database is used that contains page information from the site and what permissions the different users have on the page. Instead of redefining this information in an XML file and trying to keep two of the information up-to-date, instead, by leveraging the site navigation features in asp.net2.0, I can simply create a provider class that works directly with database information. Once this class is created and specified in the configuration of the Web site, the navigation Web control can work according to the custom navigation information of the application stored in the database. (Note: At the time this article was written, the project was still asp.net 1.x; however, this example would hopefully show you the benefits of the provider model.) )

As individuals, I think the provider model is just one of the finest migration features offered by ASP.net 2.0. ASP.net 2.0 provides a number of new features that developers must customize in the 1.x version. If the new features of these 2.0 versions use an overly "rigid" implementation, it will block the migration of the 1.x application that is being used based on the custom solution, because many new ASP.net 2.0 Web controls use these new subsystems. However, with the provider model, we can upgrade our 1.x application to version 2.0 and create a provider to integrate the 2.0 version of the new subsystem with our custom solution. This means that when migrating to version 2.0, we can use the new Web controls and make them use our existing systems naturally through the provider model.

V. Supplementary information

With the provider model becoming an important part of ASP.net 2.0, Microsoft has published a number of articles on the subject. If you want to know more about this, then I encourage you to read two of Rob Howard's articles:

· "Provider model design model and specification";

· "ASP.net 1.x provider model".

The second article analyzes how to apply the provider model to your ASP.net 1.x application. Two more articles discuss the provider usage in the site navigation subsystem of ASP.NET 2.0:

· "Understanding and extending the site navigation system in asp.net 2.0", author David Gristwood;

· "The provider in custom ASP.net 2.0," the author Morgan Skinner.

Note that Microsoft has also released another provider development Kit, which is also used to create ASP.net 2.0 providers. Furthermore, there is a good article "asp.net 2.0 provider model" for your reference.

Vi. Conclusion

A "Stiff" API implementation can "scare" developers when creating systems that are used by a large number of customers with a variety of requirements, and this "stiff" implementation tends to force customers to agree and be locked in the "vision" of the system architect. In general, companies tend to be more interested in applications and frameworks that work together with their existing programs than to force their programs to conform to vendor-supplied systems.

The provider model provides a way to break this "stiff" implementation problem. The provider model allows the system to flexibly use any class that extends a particular base class. Since then, customers can create their own derived classes that include their custom logic and business rules. Also, these new classes can be seamlessly plugged into the system without interfering with existing code in the application or any new custom code since it was created.

In summary, the provider model is commonly used in ASP.net 2.0, and these concepts can also be applied to ASP.net 1.x applications.