在ASP.NET MVC 3應用程序中使用ASP.NET的MembershipProvider會得到什麼

Question

我正在使用ASP.NET MVC 3. System.Web.Security.MembershipProvider在此MVC上下文中爲錶帶來了什麼？登錄控制不被使用。用戶會話管理（cookies等）由表單身份驗證處理而不是MembershipProvider處理，對嗎？

活動目錄集成？還有什麼？

Answer 1

我認爲Membership API仍然可以幫助您以特定於您的應用程序的方式管理某些通用概念（角色，訪問等），並且易於更新和維護。我認爲從概念上來說，成員身份的抽象概念表達的很好，所以即使您選擇使用自定義提供程序（與SQL或Active Directory的提供程序相比），Membership API也會爲添加用戶提供一致的概念，從而將角色關聯起來，維護配置文件等等。

我在ASP.NET MVC中發現，如果我想要一些在ASP.NET網站中開箱即用的行爲，我不得不付出一點努力。我必須將應用程序和會話啓動事件連接到cookie管理和創建，用戶與帳戶的關聯，補充配置文件等。但是，更改任何這些方法的持久性方法仍然可以不加修改地工作（我正在使用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本身可以。

Answer 2

這些控件實際上只是一個小小的補充 - 它們幾乎不能用於任何需要符合標準或者看起來不像Cookie應用程序的任何東西。該SqlMembershipProvider的照顧很多會員的其它醜陋的部分，如：

• 存放部件，數據安全
• 密碼會員認證
• 力學授權的簡單案件
• 機制。

至少它會給你一個功能性會員系統，直到你需要制定自己的認證方案。