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.
In ASP.NET 1.x, developers who wished to store state in alternative storage media were
faced with the daunting prospect of rewriting large portions of ASP.NET. ASP.NET 2.0, by
contrast, introduces extreme flexibility to state storage. ASP.NET 2.0 services that
manage state do not interact directly with storage media; instead, they use providers as
intermediaries, as pictured in Figure 1.
device drivers abstract physical hardware devices. Because virtually 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.
as from a database. All that's required is a custom provider. Some companies will prefer to acquire custom providers from third parties. Others, however, will want to write their own, either because no suitable provider is available off the shelf, or because they wish to adapt ASP.NET to legacy storage media (for example, existing membership
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
logging in users, recovering lost passwords, and more. Underneath the login controls sits the membership service, which provides the public API used by the controls and that can be used by application code as well. The membership service stores login credentials and other information in a membership data source, but rather than access the data source directly, it interacts with it through a membership provider. Thus, the login controls and the membership service itself can be adapted to different types of data sources (for
Now bringing you back...
Does that email address look wrong? Try again with a different email.