Understanding the Provider Model
Understanding ASP.NET Provider Model - Part 1
ASP.NET 2.0 includes host of new features such as Membership, Roles and
Profiles. These features are based on the Provider Model. This series of article
will demystify the internals of provider model and will illustrate how to create
your own custom providers.
To begin with this part explain the overall rational behind the provider
model and how it solves some of the problems faced by developers.
The need to Provider Model
Let's first understand the need for something like Provider Mode.
Consider a case of a typical user registration and login system. Such system
allows you to create, manage and authenticate users. Developers write their own
code to perform all the necessary database access. For example, in order to
authenticate a user you will develop a login page. Once the user enters the
login credentials you will fire a query against the database and check whether
his credentials are valid. Depending on the outcome you will allow or deny
access to the web site.
So far so good. However, have you ever thought as to how many times we write
this code again and again? Almost for each business application you develop you
will find yourself repeating the same steps. At first glance you may think of
reusing the code via traditional techniques - copy-paste and components. True.
That can be done to certain extent but what if the underlying database schema
differs or the authentication scheme itself is totally different. Of course, you
end us having modified version of the code again. Can't we provide a generic
layer that developers can use in their applications without bothering about
underlying database and processing logic. That's what the Provider Model is all
Provider Model at a glance
The above figure illustrates the stack of Provider Model. At the root level
you have your physical data store. This is where the actual data is stored. The
data store can be SQL Server, Access or any other database such as Oracle.
This data store is not directly exposed to your code. To isolate it from the
application all the access to the data store is managed via provider classes.
For example, if you are working with membership features using SQL Server
database then you can use SqlMembershipProvider class that shield the database
logic. You can create your own providers that contain custom implementation.
The next layer is a class called Membership (for other providers there are
other classes such as Profile and Roles). The user interface (which can be in the form a web
page or inbuilt controls such as
Login and CreateUserWizard.) uses the Membership class to get the work done. The
Membership class in turn will call the actual provider class.
With provider model in place the same tasks of creating users and
authenticating them can be done by using simple method calls - CreateUser() and
ValidateUser(). Simple and neat. Isn't it?
Providers available in ASP.NET 2.0
Out of the box ASP.NET 2.0 comes with the following providers:
- Membership Provider: To authenticate users of your web site
- Role Provider: To authorize users of your web site
- Profile Provider: To provide personalization capabilities to your web
- SiteMap Provider: To work with site map of your web site
- Session State Store Provider: To work with underlying session store
As you can see, together they make the job easy for developers. They can be
configured via web.config file to point to your own database.
This article gave an overview of the provider model of ASP.NET 2.0. In the
next part we will see how ASP.NET internally implements these providers.