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