Understanding the Provider Model
Understanding ASP.NET Provider Model - Part 2
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.