2

ここでは、複数のサブアプリケーションを含む非常に大きなアプリケーションを使用しています。(500 + dll)

開発者として、これらすべての dll と依存関係を操作するのは非常にイライラします。新しいプロジェクトを作成し、5 つ以上の dll を追加して、システムのコア部分 (ロギング、監査、セキュリティ、メッセージングなど) を機能させます。新しいサブアプリケーションを追加するたびに、Web プロジェクト、ビジネス レイヤー、データ レイヤー、および 3 つの間でオブジェクトを共有するために必要なその他のプロジェクトを作成するため、リストは拡大し続けます。

私の質問は、これを管理する最善の方法は何ですか? 私は何が最善かを考えることはできません..モジュール式のアプローチは、再利用性と、1 つのアプリケーションのシステムを停止せずにアイテムをホット パッチするのに適しているようです。しかし、500 個の dll を管理するのは悪夢です。

各サブシステムには本当に 3 ～ 4 個のプロジェクトが必要で、他の 5 つのコア部分を参照していますか?

管理/開発と展開を念頭に置いて大規模なプロジェクトを管理する他の方法は何ですか?

4

2 に答える 2

1

私は、すべてのタイプのプロジェクトでガイドラインの命名について非常に優れた経験を持っています (現在、250 以上の dll プロジェクトに取り組んでいます)。あなた（または他の誰か）が適切な命名規則を選択すると、「それ」が何であるかが一目でわかり、名前が必要なものであることがわかります。

プロジェクト内の参照数について心配する必要はありません。毎回 X 参照を追加することに不満がある場合は、代わりに X 参照を追加するマクロを作成できます。または、特別な要件を備えたテンプレート VS ソリューション/プロジェクト/アイテム (ファイル) を作成できます。

大規模なプロジェクトは大きいため、大量の dll やクラスなどを操作する必要がある場合でも、驚くことではありません。

于 2009-01-26T17:16:25.287 に答える
-1

継続中の戦いです。私たちのシステムには約 100 の異なるプロジェクトがあります。ほとんどが C# で、いくつかの低レベルの C++ プロジェクトがあります。新しい C# プロジェクトを追加する場合、基本機能を取得するためだけに、6 つの他のプロジェクトへの参照を追加する必要があります。

あなたの例では、サブアプリケーションごとに 3 つ以上のプロジェクト (Web プロジェクト、ビジネス レイヤー、データ レイヤーなど) を作成すると言います。これらのレイヤーを作成しますが、可能な限り同じプロジェクトに保持するようにします。不要なプロジェクトを追加しないようにします。サブアプリケーションが複数のプロセスにまたがる場合や、システム全体の他の部分がそのサブシステムと通信する必要があることがわかっている場合を除き、サブアプリケーションを異なるプロジェクトに分割することはありません。

各サブシステムが実際にコア部分を参照する必要がある可能性があります。3 ～ 4 個のプロジェクトが必要かどうかは、どのように設計したかによって異なります。新しいプロジェクトの作成を、他のプロジェクトと通信するか、複数のサブシステムで使用される部分に制限することで、対処しなければならないプロジェクトの数が大幅に減少することがわかりました。

于 2009-01-26T17:17:39.387 に答える