【发布时间】:2011-04-04 12:17:29
【问题描述】:
我正在使用 ASP.NET MVC 3。 System.Web.Security.MembershipProvider 在这个 MVC 上下文中带来了什么?不使用登录控件。用户会话管理(cookie 等)由表单身份验证处理,而不是 MembershipProvider,对吗?
活动目录集成?还有什么?
【问题讨论】:
标签: asp.net-mvc membership-provider
我正在使用 ASP.NET MVC 3。 System.Web.Security.MembershipProvider 在这个 MVC 上下文中带来了什么?不使用登录控件。用户会话管理(cookie 等)由表单身份验证处理,而不是 MembershipProvider,对吗?
活动目录集成?还有什么?
【问题讨论】:
标签: asp.net-mvc membership-provider
我认为 Membership API 仍然可以帮助您以特定于您的应用程序且易于更新和维护的方式管理一些通用概念(角色、访问权限等)。我相信从概念上来说,作为成员的抽象概念得到了很好的表达,因此即使您选择使用自己的自定义提供程序(相对于 SQL 或 Active Directory 提供程序),成员资格 API 也为添加用户、关联角色提供了一致的概念、维护配置文件等。
我在 ASP.NET MVC 中发现,如果我想要一些我在 ASP.NET 站点中开箱即用的行为,我必须付出一些努力。我必须将 cookie 管理和创建、用户与帐户的关联、配置配置文件等连接到 Application 和 Session 启动事件中。但是用于更改其中任何一个的持久性方法仍然可以在不修改的情况下工作(我正在使用SQL 成员资格提供程序)。
此外,拥有一些从我过去的 ASP.NET 开发经验中熟悉的元素对我来说也很有价值。按照为我的应用程序制作基本控制器的做法,我有一个用户上下文对象(很像 ASP.NET 页面如何拥有 User 对象),我可以挂起角色和配置文件。这使得为视图创建模型的各个方面变得更加容易。我可以将 UserContext 作为模型的一部分传递给视图,并且在视图中,我可以执行 Model.UserContext.Profile.LastName 或 Model.UserContext.Roles.Contains("EditOrderItems") 之类的操作。我也可以使用已经记住的角色概念来构建模型并使用用户的角色,例如:
return View(new Model{
CanEditOrders = UserContext.Roles.Contains("EditOrderItems");
...
});
虽然旧的会员用户控件可能对 ASP.NET MVC 应用没有价值,但 API 本身可以。
【讨论】:
这些控件实际上是一个次要的添加——它们几乎无法用于您需要符合标准或看起来不像千篇一律的 ASP.NET 应用程序的任何东西。 SqlMembershipProvider 负责处理成员资格的许多其他丑陋部分,例如:
至少它为您提供了一个功能性的会员系统,直到您需要制定自己的身份验证方案。
【讨论】: