zoukankan      html  css  js  c++  java
  • 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.

  • 相关阅读:
    关于IOS6屏幕旋转的问题
    学习备忘录
    关于多种手势问题
    关于 IOS中 绘制图形的问题
    爱的意义
    IOS支付SDK
    IOS开发特别备注
    ios相关教程
    iOS7光标问题
    收藏网站
  • 原文地址:https://www.cnblogs.com/igtea/p/334584.html
Copyright © 2011-2022 走看看