ソリューション内のプロジェクトが多すぎますか？

Question

1つのソリューションでいくつのプロジェクトが許容されますか？また、プロジェクト番号が大きいアプリの場合、アプリを実行できるように、他のコンパイル済みDLLをいくつかの共通フォルダーに入れますか？

Answer 1

Visual Studioではプロジェクトがアセンブリにコンパイルされるため、自分に問うべき質問は、「いくつのアセンブリが必要ですか？」

です。

アセンブリを個別に使用する理由がない場合、アセンブリを複数のプロジェクトに分割する理由はありません。階層化を強制する複数のアセンブリがある場合、それが名前空間の目的です。

理想的な設定では、アプリケーション内の異なるホストごとに1つのプロジェクト（= 1つのアセンブリ）と、ホスト固有ではないロジックに1つのプロジェクトが必要です。

YMMV、しかし、異なる部分で作業している人に応じてプロジェクトを分割したいかもしれませんが、実際には、ソリューション内のプロジェクトの数を制限してみてください（私はこれを書いているので、私は70に苦労しています+プロジェクトソリューションなので、私は個人的な経験の深fromから話しています）。

アプリケーションの論理的/物理的階層化に関する興味深い議論は、Patrick Smacchiaのブログ（たとえば、 http://codebetter.com/blogs/patricksmacchia/archive/2008/02/10/layering-the-level- metric-and-the-discourse-of-method.aspx ）

Answer 2

もちろん、42歳です！

Answer 3

これには正しい答えも間違った答えもありません。一部の開発者は、メインプロジェクト内に複数のプロジェクトを作成することを好みます。その他は、アセンブリ（dll）にコンパイルして参照することを好みます。チームと職場によって異なります。

Answer 4

これまでの回答に同意します。 1つの追加基準は、ソリューションの再構築の速度です...

Answer 5

これはプロジェクトのサイズとタイプに依存するものだと思います。しかし、私のプロジェクトの数が5以上である私自身の経験から、ビルドプロセスに長い時間がかかります。 そのため、ビルドプロセスを高速化するために、別のソリューションで頻繁に変更する必要のないプロジェクトを維持しようとしています。

Answer 6

各プロジェクトが有効で個別の機能であり、すべてのプロジェクトが密接に結合されている限り（目的が達成される限り）、それは問題ではありません。

私がしていることは、「ライブラリ」があることです。すべての外部DLLを配置したプロジェクトで、そこで直接参照します。