4

DDD 手法を使用してアプリケーションを作成しています。これは、DDD プロジェクトでの私の最初の試みです。これは私の最初のグリーンフィールド プロジェクトでもあり、私は唯一の開発者です。ドメイン モデルとユーザー インターフェイスを肉付けしました。今、私は持続層から始めています。いつものように単体テストから始めます。

[Test]
public void ShouldAddEmployerToCollection()
{
    var employerRepository = new EmployerRepository();
    var employer = _mockery.NewMock<Employer>();

    employerRepository.Add(employer);
    _mockery.VerifyAllExpectationsHaveBeenMet();
}

ご覧のとおり、Add() 関数については何も期待していません。ここまで来て、まだ特定のデータベース ベンダーを決めていないことに気付きました。実際、dbエンジンが必要かどうかさえわかりません。フラット ファイルまたは xml も同様に妥当な場合があります。だから私は次のステップがどうあるべきか疑問に思っています。

抽象化の別のレイヤーを追加する必要があります... DataStore インターフェイスと言うか、既に作業を行っている既存のライブラリを探しますか? できれば、プログラムを特定のデータベース テクノロジに結び付けることは避けたいと思います。

4

5 に答える 5

8

あなたの要件では、本当に必要な唯一の抽象化は、基本的な CRUD セマンティクスを持つリポジトリ インターフェイスです。これにより、クライアント コードと共同作業するIEmployerRepositoryオブジェクトは、具体的なリポジトリではなくオブジェクトのみを処理します。それを行うには、いくつかのオプションがあります。

1)抽象化はもうありません。トップレベル アプリケーションの必要な場所に具体的なリポジトリを構築するだけです。

IEmployeeRepository repository = new StubEmployeeRepository();
IEmployee           employee   = repository.GetEmployee(id);

100 万個の場所を変更すると古くなるため、この手法は非常に小規模なプロジェクトでのみ実際に使用できます。

2)アプリケーションで使用するリポジトリ ファクトリを作成します。

IEmployeeRepository repository = repositoryFactory<IEmployee>.CreateRepository();
IEmployee           employee   = repository.GetEmployee(id);

リポジトリ ファクトリを、それを使用するクラスに渡すか、それを保持するアプリケーション レベルの静的変数を作成します (これはシングルトンであり、残念ながら十分に制限されています)。

3)依存性注入コンテナ(基本的には汎用のファクトリおよび構成メカニズム) を使用します。

// A lot of DI containers use this 'Resolve' format.
IEmployeeRepository repository = container.Resolve<IEmployee>();
IEmployee           employee   = repository.GetEmployee(id);

以前に DI コンテナーを使用したことがない場合は、SO に関する良い質問と回答がたくさんあります (どの C#/.NET 依存性注入フレームワークを検討する価値がありますか?やデータ アクセス、単体テスト、依存性注入など)。 Martin Fowler のInversion of Control Containers and the Dependency Injection patternをぜひお読みください)。

于 2009-11-03T14:33:53.223 に答える
1

ある時点で、リポジトリがデータで何をするかについて電話をかける必要があります。プロジェクトを開始するときは、プロジェクトをできるだけシンプルに保ち、必要な場合にのみ抽象化レイヤーを追加するのがおそらく最善です。この段階では、リポジトリ/DAO を定義するだけでおそらく十分です。

通常、リポジトリ/リポジトリ/DAO は、使用することを決定したデータベースまたは ORM の実装の詳細について知っている必要があります。これが、DDD でリポジトリを使用している理由だと思います。このようにして、テストでリポジトリをモックし、実装にとらわれないようにすることができます。

于 2009-11-03T14:34:10.877 に答える
0

特に永続化テクノロジを選択していない場合は、単体テストの目的だけで、リポジトリ クラスの下に別のレイヤーを追加するべきではないと思います。永続化メソッドに関する詳細を公開せずに、「repository.GetEmployee(id)」よりも細かいインターフェイスを作成できるとは思いません。

フラット テキストまたは XML ファイルの使用を本当に検討している場合は、リポジトリ インターフェイスの抽象化に固執するのが最善の選択肢だと思います。ただし、データベースを使用することに決めたが、ベンダーについてよくわからない場合は、ORM ツールを使用することをお勧めします。

于 2009-11-04T02:39:22.343 に答える
0

永続化レイヤーで私が見つけた 1 つのことは、抽象化を開始できる場所があることを確認することです。データベースが拡大する場合は、シャーディングの実装を開始する必要がある場合があります。使用可能な抽象化レイヤーが既に存在しない限り、後で追加するのは難しい場合があります。

于 2009-11-03T20:10:28.357 に答える
0

NHibernate の上にリポジトリ パターンを実装する方法についてブログ記事を書きました。NHibernate を使用するかどうかに関係なく、役立つと思います。

一般的で拡張可能な NHiberate リポジトリの作成

于 2009-11-03T14:40:18.803 に答える