ASP.NET2.0 Provider模型

 注：本系列文章共3篇介绍ASP.NET2.0 Provider模型，这里是第一篇原文请参考如下网址： 
 
原文：http://www.dotnetbips.com/articles/displayarticle.aspx?id=491
   

    在ASP.NET2.0提供许多诸如成员（Membership），Roles（角色），Profiles（自定义配置）等特性。这些特性都构建在基于Provider的模型之上。本系列文章将揭开该模型神秘的面纱并引导您建立自己的Provider模型

   在本文开始前，我们将总体概括一下Provider模型背后的整体关系，看一下它是如何解决对于每一个开发者都面对的问题的。

Provider模型需求之因

   我们先介绍一下需要Provider模型的原因。

 
    考虑一个典型的用户注册登陆系统，这些系统允许您建立，管理和验证用户。开发人员需要自己编写代码来执行这些必须的数据访问。例如为了检验用户是否合法，您不得不建立一个登陆页面，让用户输入登陆页面所必须的凭证，然后您需要通过查询数据库来检查用户输入的凭证是否有效，并根据该结果来判断用户是否能够进入站点。

   这种做法很好，但是您是否考虑过您已经不止一次的重写这些类似的代码？几乎对于每一个业务应用程序，开发人员自己都需要重复这些相同的步骤。如果我们大致回顾一下这个过程，您可能会利用传统的“拷贝-粘贴”或者组件的方式来重用这些代码。确实，这种解决方法在某些情况下做的很棒，但是如果基础数据库以及验证模型不同了，你该怎么办？ 当然，你可以重新修改代码来生成新版本的组件。

  难道我们不能够为开发人员在它们的应用程序里提供一个具有广泛共性的逻辑模型吗？这种模型可以不受基础数据库或者业务逻辑处理的影响，这就是我们本文介绍的Provider模型

 

Provider一瞥

   上面这张图说明了Provider模型的堆栈模型，在底层你可以指定你具体数据库的使用，该数据库最终用来存放真实的数据。这里的数据库可以是SQL Server，Access数据库，也可以是其它类型如Oracle数据库  

    数据库并不会直接保露在你的代码里，为了从应用程序里分离出来，所有的对数据库的访问都会通过Provider类进行接管。例如你利用SQL Server存放数据，并使用了成员关系membership，那么你就可以使用SqlMembershipProvider类来封装对数据库访问的业务逻辑。你还可以建立你自己的Provider模型

 

   接下去的一层是一个类－－该类是Membership类（对于其它的Provider模型，会有相应的类与之对应，例如用户配置对应Profile类，角色管理对应Roles类）。  用户接口（这里的接口可以是web窗体，可以是内置的诸如Login，CreateUserWizard登陆控件）使用Membership类来进行工作。Membership类又会调用其下的provider类,。
 
   使用Provider模型来后可以简单到仅仅调用CreateUser()和ValidateUser()这两个完成类似的建立和验证用户的工作，很简单和整洁，不是吗？

ASP.NET2.0可以利用的Providers模型

  下面列出了ASP.NET2.0已经提供的Providers模型

  成员Provider（Membership Provider）：验证您站点的用户

  角色Provider（Role Provider）：授权您站点的用户

  档案Provider（Profile Provider）：用于个性化您站点的设置

导航Provider（SiteMap Provider）：使用站点地图（web.sitemap）来导航你的站点

会话Provider（Session State Store Provider）：利用基础数据库存放Session

 

正如你所看到的，整合它们将使得开发人员的工具变得简单，它们都可以通过web.config进行配置，以便指向你自己的数据库

 

总结

本文总体概括了ASP.NET2.0的Provider模型，在接下来的一节，我们将看看这些模型的执行过程