2012-06-21 61 views
2

我在使用CQRS模式的ASP.NET MVC3中開發應用程序。命令端由實體框架構成,實體映射到SQL Server中的表。查詢端建立在SQL視圖之上(也使用EF)。在CQRS中讀取模型的訪問規則

我該如何管理對數據的訪問?例如有一個文檔。文檔可以使用密碼進行保護,任何知道該文檔的人都可以訪問該文檔,或者只有給定的登錄用戶才能訪問該文檔。

在哪裏以及如何允許/拒絕訪問的邏輯應該執行? DocumentViewModel中應包含哪些數據?它是否應該包含一個密碼字段,以便將其與用戶提供的密碼進行比較,以便我可以檢查訪問並獲取數據以便在單個查詢中顯示?或者它應該只包含將在UI中顯示的字段,因此單獨的查詢(或存儲過程調用?)將負責檢查訪問權限?

如果什麼訪問規則不僅僅是檢查密碼更復雜 - 它可能包括所有白名單,黑名單,支付,轉賬限額,賬戶類型,等等? 一般 - 從東西

SELECT * FROM ReadModelTable WHERE id = @id 

,往往是表現出的「好」的閱讀情況的示例很遠。

+1

用戶應該** **認證一次,以便您可以選擇多種策略,但通常會涉及用戶名/密碼。之後,你正在處理**授權**。它總是有助於分開這兩個責任。然而,你的問題是模糊地看到從哪裏開始幫助。規範似乎是一個移動的目標,目前尚不清楚你的目標(以及是否需要基本或更高級的支持)。 –

+0

目前規範要求有2種保護文檔訪問(授權)的策略:使用與文檔本身或用戶訪問列表相關的通用密碼。或兩者。身份驗證是使用MembershipProviders實現的,並且不在域模型的範圍內。 – Pein

+0

好了,我不想與這個特殊的例子,答案,而是一個通用的模式,以應對複雜的CQRS(可能改變)的授權方案。 – Pein

回答

1

Episode 28 of Being the Worst (Podcast)具有對使用CQRS系統授權和驗證了一些有趣的點。我經常在聽取其他人的意見之後考慮認證,並提出理論體系架構作爲核心領域之外的常見問題。另一方面,授權可能包含核心領域內的元素,但在許多系統中似乎也存在一些交叉問題。

在你的榜樣,如果處理某些類型的文件彙總,其中每個都需要有一個單獨的用戶名和密碼,您的求婚會工作,然後什麼,但它聽起來並不像一個典型的實現。主要的缺點是證書與文檔一起存在,並且大概是在用戶之間共享的,這是安全問題,並且在將來會取消單個用戶的訪問權限是有問題的。想像一個祕密俱樂部,每個成員需要知道祕密密碼。如果密碼永遠不會改變,那麼當有人被踢出俱樂部或意外與非預期的派對共享密碼時,您會遇到問題。

+1

我完全意識到這個問題 - 這就是爲什麼它只是其中一種選擇。此共享密碼策略適用於用戶希望快速創建臨時工作組以審查提議的設計/項目/文檔的情況。沒什麼長久的。 – Pein

+0

在這種情況下,特設工作組密碼聽起來像是涉及域本身的業務問題。請注意,除此之外,當然在存儲和密碼比較中使用密碼散列以提高安全性是有意義的。至於在哪裏放置訪問域邏輯,聲音就像密碼本身可以成爲與該文檔實體相關的任何命令或查詢的一部分,並且可以將邏輯放置在相應的處理程序中。 – jpierson