與存儲庫模式的.NET成員關係

Question

我的團隊正在設計一個域模型，它將在統一的資源庫抽象背後隱藏各種不同的數據源。這種方法的主要驅動因素之一是這些數據源在不久的將來會發生重大變化的可能性很高，我們不希望在這種情況發生時重寫業務邏輯。一個數據源將成爲我們的會員數據庫，最初使用默認的ASP.Net成員資格提供程序實施。成員資格提供者與System.Web.Security命名空間綁定，但我們有一個設計原則，要求我們的領域模型層不依賴於System.Web（或任何其他實現/環境依賴），因爲它將在不同的環境中使用 - 我們也不希望我們的網站直接與數據庫進行通信。

我在考慮採用什麼樣的方法來協調MembershipProvider方法與抽象的n層體系結構。我最初的感覺是，我們可以創建一個「DomainMembershipProvider」，它與域模型交互，然後在模型中實現處理存儲庫和處理驗證/業務邏輯的對象。然後，存儲庫將使用我們的（尚未確定的）ORM /數據訪問工具來實現數據訪問。

這種方法是否有任何明顯的漏洞 - 我沒有與MembershipProvider類密切合作，所以可能會漏掉一些東西。另外，是否有一種方法可以更好地滿足上述要求？

在此先感謝您的意見和建議。

問候， 扎克

Answer 1

它已有6個月以來的有人問，沒有人似乎已經能夠提供一個答案，所以我想我會解釋，我們最終還是選擇瞭解決方案。

基本上，我們決定不使用MembershipProvider的任何實現 - 而是使用我們自己的自定義Membership Service坐在存儲庫上。對我們來說維護現有的aspnet_Membership數據庫非常重要，因此我們的存儲庫基本上重複了內置的SQLMembershipProvider功能（至少是我們需要的方面） - 最初通過Linq-to-SQL，但現在我們正在轉換到NHibernate 。當我們所有的網站升級到使用新模式時，計劃將在一年左右時間內取代會員資格數據庫。

有可能使用自定義成員資格提供程序，但最終顯而易見的是它使用自定義實現更簡單，更一致，更易於維護。我們仍在使用內置的表單身份驗證功能來驗證用戶是否已登錄，並重定向嘗試訪問我們網站安全區域但未經過身份驗證的用戶 - 但我們已覆蓋與配置文件提供程序綁定的功能。

最終，我們對此的感受是，儘管ASP.Net中的成員資格提供者是一個功能強大且易於使用的工具，但如果它不符合您的應用程序中使用的更廣泛的方法，那麼值得考慮另一種方法。

Answer 2

有趣的是，感謝您發佈您的最終解決方案。我處於類似的情況，但寫了一個自定義Membershipprovider。我不知道在哪裏放置提供程序，因爲它需要訪問數據庫以及System.Web命名空間。看起來這是一個違反關注設計整體分離的類。