Introduction
In the Part 1 we learnt the basic idea of ASP.NET provider model. In this part I will explain the overall architecture of ASP.NET built-in providers. Specifically we will be dissecting the membership provider.
The base classes for membership providers
Have a look at figure below:
As you can see, the base class for all the providers is ProviderBase. The ProviderBase class resides in System.Configuration.Provider namespace from System.Configuration namespace. This class is marked as abstract and it provides template for further inheritance chain. One of the important method of this class is Initialize(). This method is used to read the configuration information of the provider from web.config file and initialize the provider.
The MembershipProvider class resides in System.Web.Security namespace. This class is inherited from the ProviderBase class and adds membership specific members (especially user creation and management related members) to itself. This class is also marked as abstract.
Finally, SqlMembership class from System.Web.Security inherits the MembershipProvider class. This is a concrete class that implements properties and methods from ProviderBase and MembershipProvider specifically for SQL Server databases.
Other provider classes
Similar class hierarchy can be seen for other providers such as SQL Role Provider and SQL Profile Provider.
For example, the inheritance chain for SQL Role Provider is as follows:
ProviderBase -> RoleProvider -> SqlRoleProvider
and the inheritance chain for SQL Profile Provider is:
ProviderBase -> SettingsProvider -> ProfileProvider -> SqlProfileProvider
Abstract classes or interfaces
In .NET 2.0 I see some change in the design guidelines by Microsoft. In the previous versions of .NET they used to rely more on interfaces to provide template for framework classes. For example, in ADO.NET 1.x all the data provider classes implement certain common interfaces (IDbConnection, IDbCommand etc.). Though ADO.NET 2.0 continues to implement these interfaces it is mainly for the sake of backward compatibility. They have opted for abstract classes in ADO.NET 2.0. The same goes for provider classes. Instead of providing template via interfaces they have opted for abstract classes. The possible reasons that I can see are:
- Abstract classes can provide some implementation which interfaces can not.
- Interfaces are unalterable once implemented as that will break all the classes that are already implementing the interface.
- With abstract classes the base class can be evolved without disturbing the child classes that already inherit from it.
Summary
In this article we looked into the structure of built-in ASP.NET providers. In the next article we will develop a custom membership provider using our knowledge of Part 1 and 2.