ソリューションの読み込み時間とビルド時間に特に関心があります。ソリューションが少ないほどパフォーマンスが向上しますか?
ビルドされたアプリケーションのパフォーマンスについて言及しているわけではないことに注意してください。
少数のプロジェクトで作業する場合、ロード時間とビルド時間はより効率的ですか?
目安として、Visual Studio ソリューションには 50 ～ 60 のプロジェクトがあります。
4283 次
10 に答える
13
(ソリューションの読み込み時間とビルド時間に特に関心があります。ソリューションが少ないほど、パフォーマンスが向上しますか?)
これは、Patrick Smacchia による関連トピックで、アセンブリの数が少ない (その後、プロジェクトの数が少ない) ことの利点について説明しています。彼は、アセンブリの数がビルド時間やその他の要因にどのように影響するかについて正確に語っています。
パトリックのブログを読むことをお勧めします。コードのコンポーネント化に関する記事を多数執筆しています。
私の個人的な経験からすると、数十のプロジェクトで解決策を見つけるのは大変です。10 を超えるプロジェクトを持つ IMO では、顕著なメンテナンスの問題が発生し、生産性に影響を与えます。
于 2009-01-18T09:50:58.577 に答える
4
私はあなたのプロジェクトに依存しますが、ほとんどの場合、10-15 で作業します。プロジェクトが少ないほど、ビルド時間は短くなります。
私が通常持っているプロジェクトは次のとおりです。
- 例外とエラー処理を含む基本プロジェクト
- ビジネスの論理
- データ アクセス層 - リポジトリ
- WebForms または WinForms または WPF UI
これらのいくつかは、3 ～ 4 個の他のプロジェクトに分割します。NUnit テスト プロジェクトも用意します。
于 2009-01-18T09:35:42.927 に答える
3
パーティーに遅れましたが、これまでのところ、ビルド構成について言及している回答はありません。実行するたびにすべてをビルドしなくても、ソリューションに多数のプロジェクトを含めることができます。Debug/Release コンボをクリックして、新しいビルド構成を作成します。そこで、どのプロジェクトをビルドするかどうかを決定できます。
なぜこれを行うのですか？自由に「定義に移動」できるようにするため、また、プロジェクトを追加する手間をかけずに、ビルドの内外でプロジェクトをすばやく交換できるようにするためです。
また、ソリューション フォルダーがある場合は、フォルダーを右クリックしてビルドできます。これにより、フォルダー内のすべてのプロジェクトがビルドされます。
于 2009-08-20T13:15:23.713 に答える
3
50-60 は私には多くのように聞こえます。多くのプロジェクトでは、Visual Studio を開くのに時間がかかることがあります。他の多くのプロジェクトが依存しているプロジェクトを変更すると、ビルド時間が長くなる可能性がありますが、それぞれに 20 クラスの 10 個のプロジェクトと、それぞれに 2 個のプロジェクトがある 100 個のプロジェクトの違いはわかりません。(つまり、ビルド時のプロジェクトごとのオーバーヘッドについてはわかりません。) 何も変更しない場合でも、おそらく各プロジェクトは、何かを再構築する必要があるかどうかを検出する必要があります。無料ですが、独自のコードで試してみることなしに、より明確なものを提供することは困難です.
私はさまざまな企業に所属してきましたが、それぞれのプロジェクトにはいくつかのクラスがあり、クラスは非常に簡単に単一のプロジェクトに統合できます。私の経験では、これにはメンテナンス/管理の利点もあります。（もちろん、むやみにやらないでください - ただ分別を持ってください。）
実際にかなりの規模のプロジェクトを持っている場合は、可能であればソリューションを分割することを検討してください。それらがすべて小さなプロジェクトである場合は、それらのいくつかを結合することを検討してください。とにかく Visual Studio を待っていなくても (開く/ビルドする)、あまり心配する必要はありません。
于 2009-01-18T09:32:18.317 に答える
3
ソリューション内にプロジェクトが多すぎるのは良くありません。ビルド時間に影響します。いくつかのビルド ツールでのビルド時間の比較を行うこの記事を参照してください。記事によると、プロジェクトがビルドの一部でなくても、Visual Studio はプロジェクトごとに 2 秒かかります。
これは、Visual Studio が利用可能な最も遅いビルド ツールの 1 つであるという私の経験とも一致します。Visual Studio 6 と 2006 の間で、比較的単純な C プロジェクトのビルド時間が 1 分から 5 分に短縮されました。
于 2009-01-18T09:46:24.857 に答える
1
多くの小さなプロジェクトを作成するときに私が目にする問題は次のとおりです。
1/カプセル化: 2 つのプロジェクト間で共有するクラス、メソッド、またはプロパティは公開する必要があり、したがってどこからでも見えるようにする必要があります。プロジェクトが多ければ多いほど、秘密を漏らしている可能性が高くなります...
2/アセンブリの総数: Akuが書いたように、プロジェクトが少ないほどアセンブリが少なくなります。各プロジェクトは使用するアセンブリをローカルにコピーするため、最大 ( n * (n - 1)) / 2 個のアセンブリをフォルダーに格納できます (アセンブリ 1 の 49 個のコピー、アセンブリ 2 の 48 個のコピー、...)。50 プロジェクトの場合、これは1176ファイルです。=> OK、おそらくもっと少ない (200 ?) でしょうが、あちこちで 1 つか 2 つの古いコピーを取得するだけで十分です...
于 2009-01-18T10:36:32.650 に答える
1
そして、いくつかのマイクロソフトの言葉...
于 2009-07-17T12:21:04.853 に答える
1
私は 50 から 60 の領域で多数のプロジェクトを含むプロジェクトに取り組んでおり、開発者の怠惰/物忘れに関連する問題と比較して、長いロード時間は許容できることがわかりました。
多くのプロジェクトは基本ライブラリに依存しているため、基本ライブラリが変更されたときに再構築する必要があります。プロジェクトは常に流動的である可能性があるため、開発者がサブセットでのみ作業するということは、開発者が怠惰であると、CM ツールから更新を受け取ったときにアプリケーション全体を再構築しないことを意味します。その後、彼らは物事を修正しようとして膨大な時間を費やし、物事が壊れている理由を理解することができます. これは、依存関係ツリー全体が VS によって認識され、迅速なすべてのビルドによってすべてが適切に機能する場合にすべて解決されます。
優れた開発者はこれを知っていて、デフォルトで実行することを理解していますが、誰もが優れているわけではありません。
于 2009-01-18T12:41:25.330 に答える
0
私の意見では、それは単に個人の組織と秩序の問題です。同じソリューションの下で互いに何らかの方法で接続されている多くのプロジェクトを作成したい場合は、それを行うことができます。本当に必要かどうかを考える必要があると思います。ソリューションごとの魔法のような最大プロジェクト数はありません
于 2009-01-18T09:28:51.647 に答える
0
私が守ろうとしている一般的な方法は、ソリューションごとに 4 ～ 5 プロジェクトです。
- ビジネスの論理
- 通信層（サーバー関連）
- ユーザーインターフェース
- 他の 3 つのプロジェクトを利用/テストするためのテスト プロジェクト
これは通常、私たちのスタイルとそれを実装する方法に適合します。必要に応じて、他のものも含めることができますが、これらのインスタンスは、これらの 4 つほど一般的ではありません。
于 2009-07-17T13:06:16.567 に答える