icrosoft ASP.NET 2.0 shipped with a complete membership API that allows developers to manage the application's users and their roles. However, this API best suits small to medium web sites due to their limitation in expressing a detailed member record.
Fortunately, the Membership API is built on the provider model so you can extend it. You can use the technique discussed here to overcome this limitation and extend the Microsoft ASP.NET 2.0 Membership API to accommodate custom member records with a solution that works on top of the Membership API without requiring any change in the API.
If you're not already familiar with the provider model in ASP.NET 2.0, I highly recommend the following link: Provider Model in Depth.
ASP.NET Member and Role Management Overview
In the days of ASP.NET 1.x, managing an application's members and roles was a hectic job, especially when most of the middle and higher-level applications needed that kind of management. You would usually end up creating your own membership API to use in any application you were working on.
Microsoft ASP.NET 2.0 provides many new features, such as the Membership API, where you no longer need to worry about membership management in any application you develop. Microsoft built their Membership API upon the provider model. As with the other new features in ASP.NET 2.0, Microsoft integrated the Membership API into the .NET Framework and you can access all its objects and methods from one namespace reference, System.Web.Security.
The Membership API provides many ready-made features that you had always needed to build in ASP.NET 1.x and that took hundreds of lines of code to accomplish.
For example, the Membership API has the Login control. This control contains the username and password fields used to authenticate every user who tries to access a secure area inside the web application. In ASP.NET 1.x, you had to add this control to each application you developed. You would end up creating a User control or a Server control so you would not need to repeat your work again and again.
ASP.NET 2.0 provides a Role Management API that works with the Membership API to provide a full solution for the authentication and authorization needed for most web applications you develop. I will not spend more time on the Membership API controls in this articleyou can find many online resources and articles to get more information.
The Membership API works fine with small web applications. But a problem arises when working with huge applications. For example, the MembershipUser class, which is found in the Membership API and represents a member saved in the application's database, contains a limited number of properties. This class does not support the First Name and Last Name properties, for example. Usually, in middle to large-scale applications, a member's record requires the presence of a lot more propertiesand those properties are not all currently found in the MembershipUser class.
Although the Membership API presents a generic member's record, Microsoft built the Membership API upon the provider model, so, you can easily solve that limitation and extend the current Membership API to serve your needs.
In addition to the Membership API's need for more properties, it has another important limitation-by default it only works with Microsoft SQL Server and Active Directory. This last issue is not mainly a limitation just because Microsoft built the Membership API upon the provider model. Another provider can easily replace the model with any database implementation available.
Ways to Solve the Problem
You can choose a number of ways to overcome the limitation of the MembershipUser properties in ASP.NET 2.0's Membership API. This article will focus mainly on extending the default database that ships with the new database-related features in ASP.NET 2.0, so that you can store additional related information about a member in the web application.
|Figure 1. Membership Hierarchy: The figure shows the relationship of the various layers in the Membership API class hierarchy.|
The Membership API provider model consists of the MembershipProvider, derived from ProviderBase, which is the base provider for all the new provider-based features in ASP.NET 2.0. The SqlMembershipProvider and ActiveDirectoryMembershipProvider represent a concrete implementation of the MembershipProvider class.
The Membership class contains a set of static methods that provide the entire functionality of the Membership API to the user-interface layer in any web application. In addition, the MembershipUser class discussed above represents a single member in the Membership API database. The above can be better understood by having a look at the Membership API class hierarchy (see Figure 1
A typical scenario to overcome the limitation of the Membership API is to develop a new provider that inherits from the MembershipProvider where you override the existing methods and add more functionality as the application requires, but in this article I will show you an entirely different approach. Before I get to my new approach, here is a brief breakdown, through a simple example, of how the scenario mentioned above works so you can see the difference.
In the user-interface layer, an ASP.NET page gathers all the required information about the member using the Profile object to store the additional data. The page calls the static method, CreateUser, which is part of the Membership class. In the new membership provider, the CreateUser method would still function as before by adding the member's record into the default database; however, it will also be responsible to add the additional member-related data that was saved in the profile object previously, into a new table added to the database that will hold the additional related data on the member's record.
In this article, I will extend the Membership API in a completely different way. I will show you how to wrap the current Membership API without touching it or even inheriting from it. The basic idea is to create a wrapper over the methods that ship with the Membership API. This way you are extending the set of these methods that affect the data collected to a member's record. By extending the set, you get a richer environment to work with; the default Membership API methods are still usable in other places where there is no need to create, update, delete, and get a member's record from a database.