ASP.NET Provider Model

ASP.NET 2.0 includes a number of services that store state in databases and other storage media. For example, the session state service manages per-user session state by storing it in-process (in memory in the application domain of the host application), in memory in an external process (the “state server process”), or in a Microsoft SQL Server database, while the membership service stores user names, passwords, and other data in Microsoft SQL Server databases or Active Directory. For the majority of applications, the built-in storage options are sufficient. However, the need sometimes arises to store state in other media such as Oracle databases, DB2 databases, Microsoft SQL Server databases with custom schemas, XML files, or even data sources front-ended by Web services.

Provider Model

Goals of the Provider Model

The ASP.NET 2.0 provider model was designed with the following goals in mind:

* To make ASP.NET state storage both flexible and extensible
* To insulate application-level code and code in the ASP.NET run-time from the physical storage media where state is stored, and to isolate the changes required to use alternative media types to a single well-defined layer with minimal surface area
* To make writing custom providers as simple as possible by providing a robust and well-documented set of base classes from which developers can derive provider classes of their own

It is expected that developers who wish to pair ASP.NET 2.0 with data sources for which off-the-shelf providers are not available can, with a reasonable amount of effort, write custom providers to do the job.

Provider Types

Membership is one of several ASP.NET 2.0 services that use the provider architecture. The following table documents the features and services that are provider-based and the default providers that service them:

Membership System.Web.Security.SqlMembershipProvider
Role management System.Web.Security.SqlRoleProvider
Site map System.Web.XmlSiteMapProvider
Profile System.Web.Profile.SqlProfileProvider
Session state System.Web.SessionState.InProcSessionStateStore
Web events
Web Parts personalization System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider

Implementation Completeness

A provider is not required to implement the full contract defined by the base class it derives from. For example, a membership provider may choose not to implement the GetNumberOfUsersOnline method inherited from MembershipProvider. (The method must be overridden in the derived class to satisfy the compiler, but its implementation might simply throw a NotSupportedException.) Obviously, the more complete the implementation the better, and developers should take care to document any features that aren’t supported.

Advertisements

~ by UTS on June 7, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: