私は、ほぼ 12 のプロジェクトと 3 つの Web サイトを持つ Web アプリケーションのソリューションを手に入れました。MyProject.BE / MyProject.BLL / MyProject.DAL / MyProject.Controls プロジェクトなど、複数の Web サイトで使用するプロジェクトがいくつかあります。
私の質問は、BE/BLL/DAL/Controls 用に複数のプロジェクトを作成するのは良いことですか?それとも、BE/BLL/DAL レイヤー用のフォルダーを含む 1 つのプロジェクトを作成するのが良いですか?
「大きい」という問題は相対的なものです。ソフトウェア開発では、ほとんどの場合、PC がどれだけ優れているかが問題になります。1 秒で 100 個のプロジェクトをコンパイルして実行できる場合、ソリューション内の 100 個のプロジェクトは「小規模」です。ですから、それは本当にあなたにとって何がうまくいくかという問題です。
私の現在の作業ソリューションには、約 130 のプロジェクトがあります。はい、それを解決することはできますが、これを処理できるいくつかの印象的なボックスがあるため、130 のプロジェクトを持つコストは中程度から低く、利点はコストよりも大きくなります.
すべてのプロジェクトを 1 つのソリューションにまとめることは、すべてをすばやくコンパイル、実行、およびテストできる場合に適しています。くそー...それから、「クイック」とは何かについての会話が始まり、それはスタイルの質問です。テストを頻繁に (毎分またはそれ以上) コンパイルして実行する場合、迅速さは数秒です。1時間ごとにコンパイルして実行する場合は、数分で問題ありません。
答え：「あなたのために働く」。
注: ソリューション フォルダーを検討してください。
複数のプロジェクトを持つことは確かに良いと思います。たとえば、BE および DAL レイヤーの既存のクラスの一部を使用する WinForms UI を構築する必要がある場合は、WinForms プロジェクトからそれらのプロジェクトを参照するだけです。
私があなたの質問を理解している限り、あなたはコードをより速くコンパイルする方法やVSをオープンにする方法ではなく、ソリューションを整理する方法について言及しています。コードの方が速いですよね？
もしそうなら、ソリューション内のクラスを複数のプロジェクトに分割し、それらの目的が明確になるような名前を付けてください。あなたが与えた「BE/BLL/DAL/Controls」の例で、そのようなアプローチをすでに開始しています。
プロジェクトを指定することで、ソリューション アーキテクチャの柔軟性が大幅に向上します。ソリューションが時間の経過とともにどれだけ成長する可能性があるか、また将来どれくらい存続するかを考えてください。それをエンド ユーザーに展開する方法と、さらに重要なこととして、更新プログラムを展開する方法について考えてください。これらすべての考慮事項は、どこまで詳細に進むかの決定に影響を与えるはずです。
コードを分析し、単一責任パターンのような実証済みの設計パターンを適用する可能性があるかどうかを確認します。
開発中に数回実行され、二度と実行されない短期間の短命のツールですか? それなら、それほど努力する価値はありません。数年間維持する必要があるツールまたはアプリケーションですか? 次に、SRP パターンが慎重に実装されていることを訴えます。
Microsoft Press の次の本をお勧めします: Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern
これにより、適切なプロジェクト構造を構築するための提案、推奨事項、および基本が得られます。
ソリューションがどのように構造化されるかについての別の提案は、この SO スレッドにあります: Mvvm Applications And location of Business layer