3

Matt Petters の DDD に関するブログを読みました

それに応じて、エンティティごとにリポジトリ（インターフェース）を作成し、その後、リポジトリのインスタンス（インターフェースとして宣言）を提供するRepositoryFactoryを作成すると言われています

これはプロジェクトがDDDを使用して行われる方法ですか?

つまり、DDD を使用していると思われるプロジェクトを見ましたが、各リポジトリを直接呼び出していて、関連するファクトリはありませんでした。

そしてまた

なぜそんなに多くのリポジトリクラスを作成する必要があるのですか、なぜ次のようなものを使用しないのですか

public interface IRepository : IDisposable
{
T[] GetAll();
T[] GetAll(Expression<Func> filter); 
T GetSingle(Expression<Func> filter); 
T GetSingle(Expression<Func> filter, List<Expression<Func>> subSelectors); 
void Delete(T entity); 
void Add(T entity); 
int SaveChanges(); 
}

SOLIDの原則に違反している可能性があると思いますが、それ以外の可能性はありますか?

4

1 に答える 1

6

それにはさまざまな方法があります。それを行うための単一の「正しい」方法はありません。ほとんどの人は、ドメイン サービスをより細かく変更できるため、エンティティごとのリポジトリを好みます。これは間違いなくSOLIDの「S」に適合します。

工場に関しては、価値を付加する場合にのみ使用する必要があります。操作をラップするnewだけでは、価値はありません。

工場が価値を付加するいくつかのシナリオを次に示します。

  • Abtract Factory を使用すると、クライアント コードとは無関係にリポジトリの実装を変更できます。これは SOLID の「L」によく合いますが、DI を使用して、それを必要とするドメイン サービスにリポジトリを挿入することで、同じ効果を達成することもできます。
  • オブジェクトの作成自体が非常に複雑な操作である場合 (つまり、単に新しいインスタンスを作成する以上の操作が必要な場合)、API の背後にカプセル化するのが最適です。
于 2009-10-04T07:18:40.717 に答える