具有域驅動設計的存儲庫模式變爲反模式？

首先，我想澄清一下，我是領域驅動設計的新手，我在問這個問題，因爲我已經閱讀了一些名爲Anemic Domain Model的內容。具有域驅動設計的存儲庫模式變爲反模式？

大部分時間與存儲庫模式工作時，我看到下面的東西。

，我們沒有一個通用存儲庫
我們有型號，只有含有設置公共屬性，但它不包含任何方法（因此它成爲貧血的域模型按照DDD的定義），因爲這裏儲存庫類處理其他該實體或模型的過程。

請爲我提供查詢您的寶貴答案。

讓我澄清一些事情。

通用庫意味着得到由實體庫實現的通用接口。

我的困惑是關於以後的事

例如：假設我要救

public class User 
    { 
     public int Id { get; set;} 
     public string Name { get; set}; 
    } 

    public class UserRepository : IRepository<User> 
    { 
     // All Operation Like Save/Get/UserEntity (Domain Object)  
    }

因此，這裏是我的User類做什麼，而不是它只是有屬性等操作手柄通過UserRespository。所以我的用戶是貧血域模型。（因爲它什麼也不做具體的）

在這裏，在附加的圖像，我認爲ProductRepository所以我的問題是：我的產品類貧血的模式？

請考慮下面的示例圖片爲我所想說的。

來源

2013-08-07 dotnetstep

您能詳細說明嗎？是什麼讓你想到Repository會成爲反模式？有人的意見？你自己？如果你期望有價值的答案，請給這個問題一些價值:) –

這不是我自己的Repository是反模式，但我混淆了貧血域模型定義和存儲庫模式的方式。像Repository模式一樣，照顧實體的保存，但實體本身沒有任何保存方法。 – dotnetstep

這在DDD中完全有效，將存儲庫視爲服務。 –

Repository模式是不是一個反模式本身，而是我看到遠遠DDD的許多實現中，倉庫模式提供很少或根本沒有價值。把你的n層提供無價值的分層架構交給一個實用的核心專家開發人員，他可能會給你「反模式」的批評（我可能會這麼說）。

Repository模式的優點：

底層持久化技術
來定義你的總根源一種可能性的抽象，只有總根源應該有倉庫
的明確說明一種方法，其操作是有效的對於有問題的聚合根，例如，如果它無法刪除您的實體，那麼您的存儲庫應該沒有刪除方法。
的東西是不容易的一個數據庫來測試（磕碰的倉庫）

庫模式利弊：

貼近你的持久化技術。
尚未另一層

個人而言，我更喜歡使用存儲庫模式做DDD的時候，但你的解決方案聽起來更像活動記錄模式，從而消除大部分的在第一時間使用存儲庫的好處。我從來不會做通用的存儲庫，因爲他們刪除了專業版（我可以有一個通用的實現，但我不直接將其公開到存儲庫消費者代碼）。

另外：不要使用DTOs，ViewModels等人口儲存庫。使用單獨的模型和技術進行建模寫入（DDD可以很好地工作）和讀取。

來源

2013-08-07 07:00:29 Marius

我同意接口IRepository一般是浪費時間。如果我在我的IRepository接口中放置基本的CRUD操作，那麼如何處理審計數據等數據？刪除它將被禁止。當我嘗試致電Delete()時，是否應該返回InvalidOperationException？

有人建議使用較小的接口，如IReadable,IWriteable,IUpdateable或IDeleteable。我認爲這種方法更加混亂。對於DDD，我傾向於使用每個存儲庫的接口（主要用於IoC和單元測試）。我個人認爲這是我自己的解決方案（在給予其他所有方面的好處）。這給我IUserRepository,IAuditLogRepository等。我的存儲庫也（作爲參數）和返回域實體（聚合根或只是單個實體）。這樣就沒有貧血DTO對象來維護或混亂我的解決方案。不過，我仍然使用視圖模型來保留我的觀點中的敏感數據。

網上有很多關於存儲庫模式的參數。

來源

2013-08-07 08:29:06

具有域驅動設計的存儲庫模式變爲反模式？

回答

相關問題