2

次のようなソリューションがあります。

Project1 <—> 共有プロジェクト <—> Project2

共有プロジェクトはスタンドアロンではなく、他の 2 つのプロジェクトによってコンストラクターに注入される IUnitOfWork を受け入れるサービス レイヤーを介して、その機能を他のプロジェクトに公開します。

public SharedService (IUnitOfWork unitOfWork)
{
   ... do stuff ...
}

私が抱えている問題は、Project1 と Project2 が重複しているが異なるリポジトリ セットを持っていることです。

Project1: SharedRepository、RepositoryA、RepositoryB ...

Project2: SharedRepository、RepositoryX、RepositoryY ...

Unit Of Work がリポジトリのコンテナの役割を担っている実装を見続けています。UoW を通過してから、それらを公開するパブリック プロパティを介してリポジトリにアクセスします。

unitOfWork.SharedRepository.GetSomething();

このアプローチの結果、Unit of Work のインターフェイスは次のようになります。

public interface IUnitOfWork
{
    ISharedRepository SharedRepository();
    IRepositoryA RepositoryA();
    IRepositoryB RepositoryB();
    IRepositoryX RepositoryX();
    IRepositoryY RepositoryY();

    ... etc ...
}

ここで問題が発生します。インターフェイス IUnitOfWork は、Project1 と Project2 の両方に、互いのリポジトリを実装するように強制しています。 したがって、Unit of Work をリポジトリのコンテナーとして使用するというアプローチは、コンセプトに欠陥があるように思えます。

私はいくつかの可能な代替案を考えました：

1) IUnitOfWork を 3 つの部分 (IProject1UnitOfWork、IProject2UnitOfWork、ISharedUnitOfWork) に分割し、サービス層に ISharedUnitOfWork パラメータを受け入れさせます。面倒に思えますが、おそらくうまくいくでしょう。

2) UnitOfWork を、リポジトリのコレクションを保持するサービス ロケータに似たものに変え、必要なものを登録します。次に、UoW のコンシューマは、必要なリポジトリを取得します。

3) Unit of Work と Repositories をサービス層コンストラクターに個別に挿入します。

public SharedService (IUnitOfWork unitOfWork, ISharedRepository repository)
{
   ... do stuff ...
}

皆さんは、このような状況をどのように処理しますか? 私はオプション＃3に傾いています。より多くのものを渡す必要がありますが、代替手段はエレガントではないようです。

4

1 に答える 1

2

したがって、Unit of Work をリポジトリのコンテナーとして使用するというアプローチは、コンセプトに欠陥があるように思えます。

私もそうです。あなたの例の作業単位は、疑似サービス ロケーター (これは既に一般的にアンチパターンと見なされています) であり、SRP に違反しています。UoW は、配置したいあらゆるユース ケースの単なるトランザクション ラッパーであり、リポジトリやユース ケースに含まれるものについて何も認識すべきではありません。

そこのドミトリーの回答を参照してください：コミット時にどのリポジトリを呼び出すかをワーククラスのユニットはどのように知っていますか?

したがって、私にとっては間違いなくオプション 3 です。

于 2013-03-14T15:16:16.850 に答える