私は通常、プロジェクトをプレゼンテーション レイヤー、ビジネス ロジック レイヤー、データ ロジック レイヤーなどのレイヤーに分割します。名前空間を使用してレイヤーを分離することもあれば、(層を使用して) 3 つの個別の DLL を使用することもあります。
開発者が階層を複数の DLL に分割しているのを目にします。たとえば、100 を超えるさまざまなプロジェクト ファイル、つまり 100 を超えるさまざまな DLL を含むビジネス ロジック層を見たことがあります。また、MSDN のドキュメントには、.NET フレームワークに mscorlib などの複数の DLL が含まれていることが示されています。
個別の DLL を使用する理由は、メモリ フットプリントを最小限に抑え、複数の開発者が異なるプロジェクトで作業できるようにするためだと思います。たとえば、あるチームが 1 つのプロジェクトで作業し、別のチームが別のプロジェクトで作業するなどです。
私は 2 つの開発者チームで働いています。開発者は、個別の DLL に分割することを決定するためにどのような基準を使用しますか?
レイヤーを複数の DLL に分割する理由は何ですか?
これにはさまざまな理由があります。
コードを複数のアセンブリに分割することは、さまざまな理由で行われますが、技術的な理由もあります。アセンブリは、名前空間と同様にコードを論理的にグループ化するために使用できます。実際、一般的なパターンの 1 つは、大きな名前空間 (関心事) をその名前空間の個別のアセンブリに分割することです。しかし、その理由は、複数のアセンブリを使用する最善の理由ではないことは間違いありません。
コードの再利用は、さまざまなアセンブリにコードを配置するための最大の要因のようなものです。たとえば、コンソール アプリケーションがあり、その中のすべてのコードがコンパイルされる 1 つの実行ファイルであるとします。後で、同じアプリケーションの Web アプリ front-nd を作成することにしました。コア コードをコンソール アプリから Web アプリにコピーする代わりに、ソリューションを 3 つのプロジェクトにリファクタリングする可能性があります。コード コードのクラス ライブラリ (メインの実装)、コンソール アプリ (既に存在する)、および Web アプリです。 . コンソール アプリと Web アプリのプロジェクト/アセンブリはクラス ライブラリ プロジェクト/アセンブリを参照し、メイン コードは両方の実装で再利用されます。これは単純化しすぎです。
依存関係を管理する際に懸念事項を分離するために、コードを複数のアセンブリに分割するもう 1 つの理由。この場合、コア アプリケーション アセンブリで参照したくない Web 指向の依存関係 (他のアセンブリ) への参照を必要とするコードがある可能性があります。アプリを追加のアセンブリ/プロジェクトに分割することで、不要な依存関係を取得せずにコア アセンブリを再利用できるように、これを行います。
もう 1 つの理由は、サブチームがそれぞれ異なるアセンブリで作業する大規模なチームの並行開発を促進し、アプリケーションのさまざまな問題に取り組んでいる開発者間の「衝突」の数を減らすのに役立つことです。