私はEF->リポジトリ/UnitOfWork->サービス->MVC3階層化アプローチを使用していますが、個別のアセンブリを使用したり、アセンブリ内の論理レイヤーの一部を組み合わせたりすることの利点/欠点は何か疑問に思っていました。
基本的に私が求めているのは、実装ではなくコントラクト(インターフェース)にプログラムする場合、単一のアセンブリでそれを実行できるということです。
私はEF->リポジトリ/UnitOfWork->サービス->MVC3階層化アプローチを使用していますが、個別のアセンブリを使用したり、アセンブリ内の論理レイヤーの一部を組み合わせたりすることの利点/欠点は何か疑問に思っていました。
基本的に私が求めているのは、実装ではなくコントラクト(インターフェース)にプログラムする場合、単一のアセンブリでそれを実行できるということです。
アセンブリを使用すると、組み込みツールだけを使用してレイヤー化を強制できます。
ただし、名前空間でも同じ効果を得ることができます。NDepend などの名前空間の依存関係を検証できるツールが必要です。
インターフェイスは、この議論とは何の関係もありません。それらはコンパイル時の分離を提供します。ランタイムの依存関係はまだ残っています。静的に表示されないだけです。
ビルド パフォーマンスの観点からは、多くの場合、アセンブリが少ない方が望ましい場合があります。また、単に邪魔になることもあります (「循環参照が検出されました!」)。
個別のアセンブリのもう 1 つの利点は、コンポーネントの再利用と交換が容易になることです。たとえば、同じアプリケーションの WPF フロントエンドを作成したい場合、MVC3 プロジェクトと同じレイヤーを使用して、Web プロジェクトを WPF アプリケーションに交換するだけです。後で簡単に変更できるように、アプリケーションの明確に異なる領域を分離することは単純に理にかなっています。
複数のアセンブリを使用すると、特定のインターフェイスとクラスを内部化して、同じアセンブリ内のクラスでのみ使用できるようにすることで、「非表示」および「パブリック」インターフェイスを強制できることを意味します。これは、特定のレイヤーでヘルパー クラスと拡張クラスを使用できることを意味します。そして、「sod it」と言って、使用すべきではない場所でそれらを使用する危険はありません。
これは、名前空間などを使用するだけではできない、アプローチの階層化された性質を強制する方法です。