作業ユニットパターンを使用したビジネスレイヤーとリポジトリの接続

私の質問は、Stack Overflowでのこれと同様です。ビジネスレイヤー内で作業ユニット/リポジトリを使用する正しい方法は何ですか？

シナリオ：

• .Netソリューション
• DBからオブジェクトを取得するために使用されるIRepository
• IUnitOfWorkを使用して複数のリポジトリ間でトランザクションを許可

これは私には理にかなっていて、私はこれらの線に沿ってうまく機能する何かを実装しました。ここで、ビジネスロジックレイヤーを紹介したいと思いますが、3つの要素（BLL、UnitOfWork、およびリポジトリ）を整理することに頭が悩んでいます。

私の理解：

• リポジトリ-データの取得、操作
• UnitOfWork-永続性
• BLL-ビジネスに関連するロジック（「現実世界」）（その用語は嫌いです！）

ASP.Net MVCフロントエンドがあるとします。

BLLはどのように見え、それを使用するMVCコントローラーはどのように見えますか？

参考までに：私のIUnitOfWork / IRepository実装が私の混乱の根本的な原因であるのではないかと思います。

public class IRepository<T> 
{
    private IObjectSet<T> objSet;
    public IRepository<T>(IUnitOfWork uow)
    {
        objSet = uow.CreateObjectSet<T>();
    }

    public IQueryable<T> Add(T entity)
    {
        objSet.Add(entity);
    }
    //etc. etc. for delete, attach, getall
}

したがって、BLLがある場合は、それをIUnitOfWorkに渡して、必要なIRepositoryインスタンスを作成できるようにする必要があるように感じます。しかし、BLL（フロントエンドとは別のDLL）は、ビルドするIRepositoryの実装をどのように「認識する」のでしょうか。

私は.NETフレームワークの経験が少ないため、この回答は質問のアーキテクチャ部分にのみ関連していることに注意してください。

私が理解している限り、基本的に次のアーキテクチャパターンをアプリケーションに適用しています。

レイヤー：永続レイヤー（リポジトリパターン）、ビジネスロジックレイヤー、ビューレイヤーがあるようです。

Model-View-Controller：このパターンは、ASP.NET MVCを使用してビューレイヤーに適用されます。

問題は、BLLはどのように見え、それを使用するMVCコントローラーはどのように見えるのでしょうか。

まず、このアーキテクチャは、Robert Harveyがあなたの質問に対するコメントで述べたように、大規模なエンタープライズアプリケーションを対象としています。このようなシステムの特徴は、ドメインロジック（ビジネスロジックレイヤーにカプセル化されている）にさまざまなインターフェイスからアクセスできることです。

たとえば、Twitterについて考えてみましょう。Twitterには、ユーザーの登録と検証、ツイートの投稿などのサービスを提供するビジネスロジックレイヤーを含めることができます。このビジネスロジックレイヤーの上に、ビューレイヤーに他の複数のコンポーネント（WebインターフェイスやWebサービスコンポーネントなど）が存在する場合があります。すべてのビジネスロジックはビジネスロジックレイヤーにカプセル化されているため、DRYの原則に従い、保守性やその他の品質属性を向上させることができます。

質問に戻るには、ビジネスロジックとデータアクセスをBLLにカプセル化する必要があります。コントローラー（MVCと考える）はBLLを使用する必要があり、データベースに直接アクセスできないようにする必要があります。ビュー層をアプリケーションへのインターフェースと考えてください。

したがって、BLLがある場合は、それをIUnitOfWorkに渡して、必要なIRepositoryインスタンスを作成できるようにする必要があるように感じます。しかし、BLL（フロントエンドとは別のDLL）は、ビルドするIRepositoryの実装をどのように「認識する」のでしょうか。

BLLは、使用するリポジトリ（データソース？）を認識している必要があります。上のレイヤーはこれを制御するべきではありません。繰り返しますが、ビューレイヤーはビジネスロジックへのインターフェイスとしてのみ考慮してください。

ビジネスロジックレイヤーのオーバーヘッドが必要ない場合は、データアクセスオブジェクトの形式でデータアクセスのみに使用することもできます。

これがさまざまなコンポーネントの責任の明確化に役立つことを願っています。