0 
public class CarRepository:IC
{ 
    public IRD ReferenceDataRepositry{get;set;}
    public string SaveCar(Car car)
    {
        //get data from reference data repository
    }
}

public class ReferenceDataRepository:IRD
{
   public string Get(string id)
   {

    }

}

リポジトリにデータを保存するときに、参照データ リポジトリからデータを取得して、いくつかのプロパティを設定したいと考えています。

質問は、あるリポジトリが他のリポジトリについて知っているべきですか? 依存性注入を使用して参照データ リポジトリを設定していますが、リポジトリ内にリポジトリを設定する必要がありますか?

4

4 に答える 4

0

特定のコンテキスト用に別々のリポジトリを保持しています。クエリ リポジトリは読み取り専用ですが、通常は UI を提供します。書き込みリポジトリにはいくつかの読み取りもありますが、ドメインにサービスを提供する読み取りがあります。

public interface DomainRepository
{
 Entity Get(int id);
 bool VerifySomeAspect();
 Save(Entity data);
}

ここで、DomainRepository が読み取りと書き込みの両方をどのように機能させるかをご覧ください。原則として、目的が異なる場合は、別のリポジトリを再利用しません。

いくつかのメソッドが重複する場合は、必要なすべての引数を渡して内部および静的にしますが、別のリポジトリを挿入しません。各リポジトリに明確な責任があり、1 つのコンテキストのみを提供する場合、おそらく 95% のケースでそれを行う必要はありません。

これは、一般的なリポジトリを使用しないことも意味します。レイヤー/コンテキストのニーズに応じて各リポジトリを設計し、「できる限り再利用する必要がある」という罠に陥らないでください。再利用は良いことですが、この状況では注意が必要です。

于 2012-06-13T10:46:34.037 に答える
0

DI は単にオブジェクトが別のオブジェクトに依存していることを示していますが、依存関係をインスタンス化する責任はありません。

ただし、読み取りリポジトリを書き込みリポジトリに挿入します。読み取りと書き込みはまさにそれです。オブジェクトを取得し、オブジェクトを保存します。オブジェクトを実際に変更する責任はまだあります。これは別のコンポーネントで発生します。コントローラー アクションやサービス ファサードのように。

于 2012-06-09T14:46:25.930 に答える
0

リポジトリはお互いを認識すべきではないと思います。この追加の動作は、サービスまたはビジネス レイヤーに属します。

リポジトリ パターンとは、データ アクセス レイヤーをビジネス レイヤーから分離し、さまざまなリポジトリを結合することで、ビジネス ロジックをデータ レイヤーに滑り込ませることです。これは、この設計パターンを使用する当初の目的に反します。

ところで。データを変更するメソッドと、データを読み取るメソッドを分離することをお勧めします。

于 2012-06-09T14:50:26.120 に答える
0

Microsoftが説明するリポジトリ パターンは、ロジックのカプセル化と、データを取得してエンティティ モデルにマッピングするロジックを、モデルで動作するビジネス ロジックから分離する方法に関するものです。

異なるロジックを混同する必要はありません。各リポジトリは 1 つをカプセル化します。

しかし、そのようなものが必要な場合は、異なるリポジトリ間のもつれを処理する RepositoryManager クラスを作成できます。

于 2012-06-09T14:51:24.453 に答える