9

この質問には、他の関連する質問がいくつか含まれています。1 つまたは複数の質問に自由に答えてください。

  • プロジェクト/DLL を分離する利点は何ですか?
  • プロジェクト/DLL を分離することの欠点は何ですか?
  • 共有可能なリソースごとに新しいソリューション/DLL を作成すると、多くのプロジェクトになりませんか?
  • あまりにも多くのプロジェクト (40 以上など) の後、これは IDE のパフォーマンス (VS.NET 2008) に悪影響を及ぼしますか?

この質問をするのは、非常に多くの異なるクラスを持つこの大きなソリューションを手に入れたからです。また、いくつかのインターフェイスを分離する必要があり、すべてバラバラになっているため (循環依存関係の問題)、複数の DLL を作成する必要があるため、単にしたいだけです。今回は必ず正しい方法で行ってください。

4

6 に答える 6

6

この質問への答えは、議論の範囲に関して非常に長くなる可能性があります。まず第一に、何が選択であり、複数のアセンブリでアイテムを分離する必要が生じた理由に焦点を当てる方がよいと思います。一般的に、これは次のようになります。一般的に、デザインとレイヤリング、および/またはプロジェクト構造をきれいにします。

1. ソリューションと DLL を分離する利点は何ですか?

一般に、ソリューションとアセンブリを分離する利点は、デザイン アプローチ、コードの再利用、およびレイヤー構成に関連しています。前述のように、ソリューションを分離すると、オブジェクト/コンポーネントを共有し、レイヤー間で責任を分散し、マルチターゲットおよびプラグ可能なソリューションを促進するのに役立ちます (参照たとえば、さまざまなストレージ ターゲット アセンブリ (データベース、ファイルなど))、テスト容易性

2. ソリューションと DLL を分離することの欠点は何ですか?

他の人が私の前に言ったように、主な欠点は、まず複雑さ（管理、保守）、次にパフォーマンスです（ただし、これは別の議論であり、それを言うのは簡単ではありません）

3. 共有可能なリソースごとに新しいソリューション/DLL を作成すると、多くのソリューションにはなりませんか?

それは依存します、まず第一に、これはデザインの選択に依存する可能性があると思います

4. あまりにも多くのソリューション (40 以上など) の後、これは IDE のパフォーマンス (VS.NET 2008) に悪影響を及ぼしますか?

VS2008 IDE のパフォーマンスの低下についてはよくわかりませんが、たとえば、それぞれ 20 のプロジェクトを持つ 4 つのソリューションよりも、60 以上のプロジェクトの単一のソリューションを管理する方がパフォーマンスに影響を与える可能性があることは確かです.VS IDE のパフォーマンスが低下する可能性があることは明らかです。たとえば、1 つまたは 2 つのプロジェクト ソリューションから 35 個のファイルを一緒に開いた後でも..

最後に、私が心に留めておくべき重要なことは、たとえば過度の設計に陥るよりも、本当に必要なものだけを「構築」する方がよいということです。立ち止まって「すべてうまくいっているの？」と思うこと。

于 2009-04-27T11:41:07.810 に答える
3

利点

  • 目的の明確さ。
  • 1 つの dll を置き換えて、残りのアプリケーションを以前と同じように動作させる機能。
  • 再利用性 (ただし、これは過大評価されることがよくあります*)。

短所

  • 作業の難しさ (7 つのプロジェクト間を行き来するだけでも大変です)。
  • 新しいタイプの依存関係の問題の可能性 (プロジェクト A がプロジェクト B を参照することも、その逆も可能ですが、両方を参照することはできません)
  • デプロイする DLL がたくさんあります。

一般に、(ビジネス ロジックを UI から分離するために) 少なくとも 1 つの DLL を使用することをお勧めします。そのコードのすべてを必要としないアプリケーションのバージョンが異なる場合は、さらに多くの DLL を使用することをお勧めします。

*私たちはしばしば、そのすばらしい Order クラスを再利用できると自分自身に信じ込ませます。私たちはおそらくしません。ドメイン モデルは異なる傾向があります。

于 2009-04-27T12:03:16.053 に答える
2

多くのdllの主な欠点は次のとおりです。

  • 複雑さ (管理および展開する膨大な数の dll)
  • 「フュージョン」のパフォーマンス (ILMerge を使用して削減できます)

利点はより多くの分離ですが、実際には、単一の (またはいくつかの) dll 内で同じ (または同様の) 分離を実現できます。

循環依存関係の問題については、おそらく「依存関係の注入」と「制御の反転」を確認する必要があります。

于 2009-04-27T10:39:16.303 に答える
1

一般に、コード内で依存関係が論理的に分離されている場合は、常に分離する必要があります。たとえば、すべてが共通のコアに依存する関連する小さなアプリケーションのスイートを構築している場合、コア クラスを含む 1 つのライブラリと、そのようなアプリケーションごとに 1 つのライブラリを用意することは理にかなっています。この種の分離を反映した単純な依存関係グラフを次に示します。

         +------------> Core <------------+
         |               ^                |
         |               |                |
   Level Builder         |           Game Server
         ^               |
         |               |
         +-----------Game Client

最後に、.NET には、条件付きコンパイル以外にテストのみのコードの依存関係を保持する優れた方法がないため、さまざまなテストを別のライブラリに置くこともお勧めします。

于 2009-04-27T10:37:17.790 に答える
1

私はあなたの問題の反対と戦ってきました-dllと依存関係が多すぎます。

答えはわかりませんが、いくつかの役立つヒントが得られるかもしれないいくつかの質問を以下に示します。

C# での大規模な winforms アプリケーションのプロジェクトと依存関係の構造化
Visual Studio でプロジェクトをアンロードするときの参照についてはどうしていますか?

同じ dll に異なる名前空間を持つことができることに注意してください (逆に、名前空間を複数の dll に分散させることもできます)。

多くのプロジェクトを含む私のソリューションでは、現在、「WorkingSetOnly」と呼ばれるカスタム ビルド構成 ([デバッグ/リリース] コンボをクリックして [構成マネージャー] を選択) をセットアップしており、コンパイルするかどうかを選択できます。 Run の各プロジェクト - これにより、実行が速くなりますが、IntelliSense、goto 定義などは保存されます。また、ソリューション フォルダーを使用して、プロジェクトを 2 つの「バケット」 (WorkingSet とその他) に整理しますが、2 つをリンクする方法はまだ見つかりません ( config およびフォルダー) を自動的に。

于 2009-04-27T11:38:45.600 に答える
0

循環依存の問題とは、次のことを意味します。

[Lib1]

[Project1]
  [ClassA]

[Project2]
  [ClassB]

ClassA と ClassB が相互に参照している場合、それらを Lib1 に引き出し、Project1 と Project2 が Lib1 を参照するようにする必要があります。そうしないと、Project1 と 2 の同期を維持することが非常に難しいからです。

これは暴走するという意味ではなく、IDE のパフォーマンスが大きな問題になることはないと確信しています。40 以上のプロジェクトがある場合、設計上の問題が発生しています。

于 2009-04-27T11:52:06.690 に答える