14

まず最初に、私がドメイン駆動設計に慣れていないことを明確にしたいと思います。この質問をしているのは、Anemic Domain Model と呼ばれるものを読んだことがあるためです。

ほとんどの場合、リポジトリ パターンを操作しているときに次のようなことがわかります。

  1. 1 つの汎用リポジトリがあります
  2. ここでは、リポジトリ クラスがそのエンティティまたはモデルの他のプロセスを処理するため、パブリック プロパティのセットのみを含むモデルがありますが、メソッドは含まれません (したがって、DDD の定義に従って Anemic Domain Model になります)。

私の質問に対する貴重な回答を提供してください。

いくつかのことを明確にさせてください。

ジェネリック リポジトリとは、エンティティ リポジトリによって実装されるジェネリック インターフェイスを意味します。

私の混乱は次のことに関するものです

例：保存したいとします

    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です。したがって、私のユーザーはAnemic Domainモデルです。（特に何もしないので）

ここに添付された画像で私が考えているProductRepositoryので、私の質問は次のとおりです。私の製品クラスは貧血モデルですか?

私が言おうとしていることについては、次のサンプル画像を検討してください。

ここに画像の説明を入力

4

2 に答える 2

22

リポジトリ パターン自体はアンチ パターンではありませんが、リポジトリ パターンがほとんどまたはまったく価値を提供しない DDD の多くの実装を見てきました。価値のない n 層のレイヤード アーキテクチャを実用的な筋金入りの専門家の開発者に渡せば、彼はおそらく「アンチパターン」の批判をするでしょう (そして、私が言うには有効です)。

リポジトリ パターンの利点:

  1. 基礎となる永続化テクノロジの抽象化
  2. 集約ルートを定義する可能性。集約ルートのみがリポジトリを持つ必要があります
  3. 問題の集約ルートに対して有効な操作を明示的に示す方法。たとえば、エンティティの削除が有効でない場合、リポジトリには削除メソッドがありません。
  4. データベースなしで簡単にテストできるもの (リポジトリのスタブ化)

リポジトリ パターンの短所:

  1. 永続化テクノロジへの近さ。
  2. さらに別の層

個人的には、DDD を実行するときにリポジトリ パターンを使用することを好みますが、ソリューションはアクティブ レコード パターンのように聞こえるため、そもそもリポジトリを使用する利点のほとんどが失われます。一般的なリポジトリは長所 2 と 3 を削除するため、私は決して行いません (一般的な実装を行うことはできますが、リポジトリ コンシューマ コードに直接公開することはありません)。

また、DTO、ViewModel などの作成にリポジトリを使用しないでください。書き込み (DDD はうまく機能します) と読み取りのモデル化には、別のモデルとテクノロジを使用してください。

于 2013-08-07T07:00:29.117 に答える