VS 2005 の場合、パフォーマンスの問題を引き起こすプロジェクトの最大数はありますか。現在、最大 25 のプロジェクトがあり、さらに増えています。これらのバイナリ参照を作成する必要がありますか、それともアプリケーション ロジックをあまりにも多くの異なるプロジェクトに分割する必要がありますか。最近、大きなパフォーマンスの問題になり始めているようです。
4 に答える
5
DLL ファイルが多すぎると、実行時にコストがかかる可能性があるため、プロジェクトの量を最小限に抑えることをお勧めします。複数のソリューションを作成することもできますが、複数のソリューションにわたって新しい機能をデバッグして実装する必要がないように、ソリューションを互いに独立させてください。これは煩雑になる可能性があります。
この記事をご覧ください:プロジェクトのアンチパターン: Visual Studio ソリューション ファイル内の多数のプロジェクト。
于 2008-11-16T15:08:25.853 に答える
1
通常、ソリューション内のプロジェクトの量を10未満に維持しようとします。10を超えると、コンパイル時間が遅くなり、「プロジェクトの再読み込み」時間が遅くなります。
しかし、ここでの主な問題は、なぜ26のプロジェクトがあるのかということです。単純なWebサイトでは、データ層、ビジネス層、プレゼンテーション層をすべて同じプロジェクト内に保持しながら、プロジェクトを1つだけ持つことができます。
この3層のものだけのプロジェクトを分割する場合は、これを修正することをお勧めします。例として、3層のプロジェクトが3つあります。別々のアセンブリに3つの層がある理由は、プロジェクトの後半でデータ層を使用するために他のソフトウェアを実行しているためです。ビジネスレイヤーをメインのプレゼンテーションプロジェクトの外に置くことで、プレゼンタティエ層の外に無用な依存関係を保ちながら、ビジネス層を簡単に単体テストできます。
したがって、全体として、プロジェクトを10未満に保ち、いくつかのプロジェクトを統合できるかどうかを確認します。コンパイル時とビルド時の両方で時間を節約できます。また、これらのDLLの管理もより簡単になります。
于 2008-11-17T03:33:34.337 に答える
1
25のプロジェクトすべてに依存関係の連鎖がありますか？一部のプロジェクトが他のプロジェクトに依存していない場合は、それらを独自のソリューションに入れてください。
必要がなく、通常はコンパイルしない場合は、ソリューション全体をコンパイルしないでください。通常、変更したばかりのプロジェクトを右クリックして、それだけをコンパイルできます。VSは、どの依存プロジェクトを再コンパイルする必要があるかを判断します。
ブレークポイントに到達する予定がない限り、「デバッグなしで開始」を使用してください。
一部のDLLは安定していて、長期間変更されていませんか？それらもソリューションに含まれている必要はありません。
本当に必要な場合を除いて、ソリューション全体を検索しないでください。
本当の制限は人間の心です。1つのプロジェクトでいくつのファイルを処理できますか？また、依存関係を追跡するためにndependsを使用していない限り、1つのプロジェクトに多くのクラスを配置すると、他のクラスに依存するクラスが多すぎて、変更がより困難でリスクが高くなる可能性があります。
于 2008-11-17T03:23:13.733 に答える
0
実行時ではなくビルド時にコストがかかると思います。少ないほど高速ですが、常にすべてをビルドするとは限りません。その場合は、量を減らす必要があります。それ以外の場合は、それらを異なるソリューションに分割します。次に、ビルドサーバーだけがそれらすべてをビルドする必要があり、毎日のビルドではビルドに徹夜します;-)
于 2008-11-16T16:54:27.497 に答える