ASP.NET MVC3：我需要使用MembershipProvider嗎？

Question

我正在用MVC3構建一個多租戶網站。在這個項目之前，我從來沒有碰過.NET堆棧或一般的Web開發，所以你可以想象我的領域知識有點缺乏。

我仍然使用默認的AccountController體系結構，但我很快就確定我不想使用aspnetdb.mdf進行身份驗證，因爲它的設計與我的要求非常不同。我確實需要基於角色的身份驗證，因此我最終將自定義用戶和角色類編寫爲代碼優先的實體類，並使用this tutorial來設置自定義MembershipProvider和RoleProvider。

目前一切正常，但由於我構建的多租戶功能越來越混亂。根據this example，我使用Controller的自定義擴展來跟蹤哪個租戶正在使用此會話，並且所有控制器都擴展此類而不是基本Controller類。

所有租戶都使用相同的數據庫。每個實體都有一個租戶屬性，用於標識其所屬的用戶。

所以，這裏的問題：
用戶名不必是全球唯一的。只有用戶名和租戶的組合必須是唯一的。因此，ValidateUser需要知道用戶名，密碼和租戶。由於我的自定義MembershipProvider不是控制器，它不知道哪個租戶正在使用該會話，並且ValidateUser方法只接受用戶名和密碼，因此我無法將該信息傳遞給它。

此外，幾乎所有的MembershipProvider的工作除了ValidateUser已經實現在一個UserRepository類，該教程告訴我做的。我非常喜歡Repository模式，它比堅持MembershipProvider的界面更方便，但是現在UserRepository和MembershipProvider之間存在巨大的利益衝突。

所以，我的問題：
我需要使用的MembershipProvider，甚至會籍，在所有？
似乎所有MembershipProvider所做的都會由我的存儲庫類更方便地執行。在這一點上，我所要做的就是編寫一個不依賴於Membership的新Authorize屬性，並且一切都應該在沒有任何MembershipProvider的情況下運行，對吧？如果我不放棄會員資格，我不得不徹底毀掉我的MembershipProvider實現，以至於它幾乎不管原始界面。

...無論是那個或成員做了很多我不知道的東西，並刪除它是公然的愚蠢。這也是一個明顯的可能性。

Answer 1

根本不需要使用成員資格提供者。它只是作爲一個快速和一致的方式來啓動和運行。有些人選擇它是因爲它支持多個數據庫（通用成員提供者包括azure以及sql ce，express和full），但對於試圖將其映射到應用程序規則的其他人來說，它可能比它需要的代碼更難驗證併發布自己的表單驗證票證。

這樣說我假設你使用表單身份驗證。您可以直接自行發票。我仍然會針對默認MVC模板應該具有的接口進行編程，因此只需添加一個新的租戶ID即可。

就這樣說，我會考慮有獨特的名字。它確保您不會忘記在應用程序中的其他位置執行額外的租戶檢查，並且tenant1 \ userBip和tenant2 \ userBip出乎意料地會在某個時刻踩到其他每個人的記錄。

真，測試應該發現這一點 - 如果測試完成：）

Answer 2

不，你並不需要使用會員，但考慮了一會兒成員到底是什麼。成員資格不涉及您的用戶名稱，地址或其他信息。會員資格嚴格與系統的登錄帳戶相關。它只處理創建，驗證，更新或刪除登錄所需信息的細節。而已。

同樣，角色系統僅爲用戶分配角色名稱。

最終，成員資格和角色只是IPrincipal接口的實現。而FormsAuthentication是IIdentity接口的一個實現。這些一起工作，以便您可以使用內置的ASP.NET授權和身份驗證系統。

成員資格實際上確實具有多個端點的概念。此功能是通過aspnet_Users表格內

從上Membership類的文件（在Membership類本身也可設置）的「ApplicationNane」字段來實現：

的應用程序名稱被用來識別特定的用戶一個應用程序。也就是說，數據庫中可以存在用於指定不同ApplicationName的多個ASP.NET應用程序的相同用戶名。這使得多個應用程序可以使用相同的數據庫來存儲用戶信息，而不會遇到重複的用戶名衝突。或者，多個ASP.NET應用程序可以通過指定相同的ApplicationName來使用相同的用戶數據庫。 ApplicationName可以通過編程或聲明方式在Web應用程序的配置中進行設置。

現在，這樣的設計是典型地在web.config中設置，並保持對應用程序的生命一樣，但是我不明白爲什麼你不能用它來指定要哪個坦。

這裏唯一的問題是，Membership.ApplicationName是靜態的，這意味着它在應用程序池正在運行的所有線程共享。但是，如果您在訪問它時使用某種鎖，那麼這不應該是一個大問題（儘管它可能會影響某些級別的可伸縮性）。

這基本上允許您使用標準的開箱即用型會員供應商而無需任何更改。您只需確保保護訪問電話。