18

私は新しいプロジェクトを開始しており、DDD パターンを組み込み、Linq to Entities も含めることにしました。EF の ObjectContext を見ると、Repository パターンと Unit of Work パターンの両方の機能を実行しているようです。

基になるデータ レベル インターフェイスがエンティティ表現から抽象化され、ObjectContext を介してデータを要求および保存できるという意味でのリポジトリ。

すべての挿入/更新を objectContext に書き込み、SaveChanges() を実行するときにそれらすべてを一度に実行できるという意味での作業単位。

これらのパターンの別のレイヤーを EF ObjectContext の上に置くのは冗長に思えますか? また、モデル クラスは、「部分クラス」を使用して、EF で生成されたエンティティの上に直接組み込むことができるようです。

私は DDD を初めて使用するので、ここで何か不足している場合はお知らせください。

4

3 に答える 3

17

Entity Frameworkは、リポジトリの優れた実装ではないと思います。理由は次のとおりです。

  • オブジェクトコンテキストは、DBアクセスにバインドされているため、それを参照するものの適切な単体テストを行うには十分に抽象的ではありません。代わりに、IRepository参照があると、単体テストを作成するのにはるかに効果的です。
  • クライアントがObjectContextにアクセスできる場合、クライアントは気になるほとんどすべてのことを実行できます。これを実際に制御できるのは、特定のタイプまたはプロパティをプライベートにすることだけです。この方法で優れたデータセキュリティを実装することは困難です。
  • 自明でないモデルでは、ObjectContextは十分に抽象的ではありません。たとえば、テーブルとストアドプロシージャの両方を同じエンティティタイプにマップすることができます。クライアントが2つのマッピングを区別する必要はありません。
  • 関連する注記として、包括的で十分に実施されているビジネスルールとエンティティコードを作成することは困難です。確かに、これが良い考えでさえあるかどうかは議論の余地があります。

一方、ObjectContextがあれば、リポジトリパターンの実装は簡単です。実際、特に複雑ではない場合、リポジトリはObjectContextとEntityタイプのラッパーのようなものです。

于 2009-02-06T12:53:22.387 に答える
7

ObjectContext をリポジトリとしてではなく、UnitOfWork として見る必要があると思います。

ObjectContext は「汎用」であるため、リポジトリにすることはできません。通常の CRUD メソッドの横に特殊なメソッド (たとえば、GetCustomersWithGoldStatus など) を持つ独自のリポジトリを作成する必要があります。

したがって、私がすることは、リポジトリ (集約ルートごとに 1 つ) を作成し、それらのリポジトリが ObjectContext を使用できるようにすることです。

于 2009-02-06T13:06:30.050 に答える