使用存儲庫設計模式組織類

Question

我已經開始升級使用ASP.NET Web窗體編寫的內部軟件應用程序之一，並轉移到ASP.NET MVC。

我想利用我的類的存儲庫設計模式，這導致我的問題是多少放入存儲庫。

我有以下實體：

• 主題
• 主題評論（主題可以有多個評論）
• 主題版本（任何時間編輯的主題，修訂記錄）
• 主題訂閱（允許用戶 訂閱特定 主題的更改）

我目前有一個ITopicRepository的接口和一個名爲TopicRepository的類，它處理一個Topic的所有基本CRUD。我現在準備爲評論，修訂和訂閱添加代碼。

我想知道是否所有這一切都進入了TopicRepository，或者我爲每個實體創建一個存儲庫，例如TopicRevisionRepository等等。

Answer 1

平均MVC數據訪問策略與存儲庫模式的域驅動設計理解之間存在相當大的脫節。

對於ASP.Net MVC，您將看到的大部分示例僅比ActiveRecord稍微輕微一些，使用每個實體的Repository對象。他們實際實施的是一種表格數據網關，使用Repository而不是Gateway。

對於許多應用程序來說沒有任何問題，我通常用相同的方法開始新的應用程序，直到我可以證明我需要不同的東西。但是，通常借用存儲庫概念的域驅動設計原則需要通過聚合根存儲庫確定聚合根併合並這些子實體的數據訪問。這使您可以在數據存儲的狀態更改周圍設置邊界，並且可以幫助實施事務性更改等等。

編輯添加：在你的例子中，你似乎很不可能修改任何這些子對象與父母分離，所以我很想說一個「主題」是一個聚合根你的域名。

Answer 2

在我看來，它應該進入它自己的倉庫......

編輯：域和數據使用集合類 接口，用於訪問域 映射層之間

介導 對象。

Repository Pattern

這樣，如果你的興趣使用一個通用的倉庫就像this example這意味着更少的代碼...

Answer 3

望着NerdDinner tutorial，他們似乎去與每個實體程序存儲庫。

當你考慮它時，這是有道理的。在某些情況下，您想要控制何時加載子實體。

Answer 4

我認爲這取決於你將如何訪問你的數據。變化是你總是會看到一個主題與其評論，反之亦然，像（32）評論UI元素。

因此，您的主題變成了Aggregate Root，您只需要一個存儲庫用於此方法。

要考慮的一件事是，如果你有很多小東西，你只需要非常狹窄的訪問權限就像一個下拉選項的列表，你真的不想要一個完整的存儲庫。問題在於，一旦你通過了20個實體，你最終將有20個接口和20個存儲庫在你的解決方案中考慮。

它非常實用，只爲您的聚合根擁有存儲庫並將其他值類型存儲庫保存在一起。例如DropdownlistRepository或其他東西。

最後，您在項目階段的性能問題並不重要，爲「主題」檢索整個對象圖可能不是那麼糟糕的性能。保持簡單，如果您使用ORM映射器，它應該能夠處理每次需要時爲其提供該主題，並且其所有子實體都被延遲加載。