3-tierアーキテクチャの依存関係

Question

私は3層アプリケーションをどのように構築するのかと苦労しています。私はいつも私が望んでいない依存関係の問題に終わっているように思えます。これは私が間違っていることを示す兆候です。

通常、3層アーキテクチャはどのように構成していますか？

私はこれを行うには、2つの方法のいずれかが表示

：

1. ビジネス層は、（あなたがそれを見てどのように応じて、または下）一番上にある広告他のすべての層がそれに依存します。ビジネスレイヤーは、特にデータアクセスのために必要なインターフェースを定義します。データアクセス層はこれらのインタフェースを実装し、依存層注入を使用してそれらを中間層に注入します。同様に、UIもDIを介して出力インタフェースを消費します。ビジネスオブジェクトは、データレイヤーがいっぱいになるPOCOです。データレイヤーには独自のコードモデルがありません（ビジネスレイヤーで定義されたビジネスオブジェクトを使用します）。ビジネスレイヤは、UIまたはデータレイヤ、UIおよびデータレイヤのいずれかがビジネスレイヤについて知っていることは何も知らない。
2. UIティアは一番上に、ビジネスは中に、データは一番下に、データ層は、ビジネス層が消費するインタフェースを公開します。ビジネスには、UIが消費するインターフェースがあります。まさに1-2-3の状況だ。データレイヤーはコードオブジェクトを定義し、ビジネスレイヤーは独自のモデルを持っています（AutoMapperはそれらの間のマッピングに使用されますが、このマッピングはビジネスレイヤーで実行されます）。データレイヤーはビジネスレイヤーやUIレイヤーについては何も知らない。ビジネスレイヤはデータレイヤを認識しますが、UIレイヤは認識しません。 UIレイヤーはビジネスレイヤーを認識しますが、データレイヤーは認識しません。

あなたはこれらのいずれかを使用していますか？どれ？どうして？別のアプローチを使用していますか？

私はそれを見て、＃1はビジネス中心の方法を提供しています。ビジネスレイヤに影響を与えることなくUIをデータレイヤと同様に簡単に変更できます。

2番目の方が簡単です。通常、データレイヤーが変更されるとビジネスレイヤーが変更される必要があります。もちろん、よく計画されたインターフェース（リポジトリパターンのように、これを変更する必要があるところ）でこれを抽象化することができます。 UIはどちらにも影響を与えることなく変更できます。

Answer 1

ビジネスロジックがほとんどないCURDアプリケーションの場合は、アプローチ＃2を使用します。 それ以外の場合は、アプローチ＃1を使用します。実際には、Inversion of Control（IoC）を＃2に適用した結果です。