Introduction
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 about!
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 site
- 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.
Summary
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.