WPFアプリケーションを複数のdllに分割するのが良いか悪いですか？

Question

以前のWPFアプリケーションのサイズは、1つの.exeファイルとして4096KBでした。

今私は、私はさらにJIMS.ViewModel.dllにJIMS.exeからのviewmodelsを除去することにより、さらに2つのDLLを追加するために考えています。この

JIMS.exe   Main Application-->103KB 
JIMSDAL.dll  Data Access Layer-->43KB 
JIMS.Core.dll  Core classes for MVVM-->110KB 
JIMS.Commands.dll MVVM Commands-->11KB 
JIMS.Controls.dll WPF UserControls-->25KB 
JIMS.Resources.dll Fonts,icons and xaml resources.-->44KB 
UtilityClasses.dll Other classes like Helper classes-->10KB 

のように複数のようなアプリケーションを分割されています。

今、私の質問は、これは

私はこれの長所と短所は何か教えてください、複数のDLLにシングルEXEを吐くための良い方法です。

多くのDLLがある場合、JIMS.exeはアプリケーションを使用して多くのDLLに接続するのに苦労します。呼び出しごとにそれぞれのdllを読み込む必要があるためです。

ありがとうございます。

Answer 1

私はそれが言及見ていないので、私はチップよ私の経験で

、C＃で、このアプローチを使用する主な理由は、exchangeabilityある - 。簡単にシステムの部品を交換できるようにします。

例として、私は現在のプロジェクトでこのアプローチを使用します。各GUIコンポーネント（またはUserControl）は独自のdllで、起動時に動的にインポートされます。これにより、私たちはGUI用のプラグインアーキテクチャを実装することができます。また、GUI開発者が別々のプロジェクトで作業し、すべてのロジックをロードする必要がなくなります。

"良い"か "悪い"かはわかりませんが、それはあなたの特定の目的に必要なものです。私が言うことができるのは、が「間違っています」ではないということです。

Answer 2

他のプロジェクトでこれらのDLLを単独で使用する場合は、それらを分割することができますか？私はあなたのアプリケーションについてはわかりませんが、他の開発者やアプリケーションが他のアプリケーションに統合されるために、コントロールを作成している場合、dllを別々に管理するのは難しい作業になるかもしれません。あなたの最後の意見についてはあまりよく分かりません。私はそれに向かってコミュニティの入力を見たいと思います

Answer 3

複数のdllでアプリケーションを分割するのは良いです。これにより、プロジェクトの管理が容易になり、機能の追加/削除が容易になり、既存のDLLを使用して完全に新しいアプリケーションを簡単に作成することができます。 私はダイナミックについて

良いものは、あなたのサブルーチンで何かを変更する場合は、アプリケーションを再リンクする必要はありません

1. を呼び出します.....動的リンクは、アプリケーションのために優れていると思います。サブルーチンDLLのみを再リンクする必要があります。
2. このサブルーチンを呼び出すすべての実行可能ファイルは、同じDLLを共有します。コードとデータの両方アプリケーションでは、動的に呼び出されるサブルーチンのコピーが1つしか読み込まれないため、メモリの使用量が少なくなります。
3. 動的に呼び出されるサブルーチン内に含まれる値の変更は、サブルーチンのすべてのコピーを共有するため、サブルーチンを使用するすべてのDLLで使用できます。
4. 動的に呼び出されるサブルーチンが使用していたメモリを解放するには、サブルーチンをキャンセルします。しかし、これは、32ビットのWindows仮想メモリ環境では一般的にあまり使用されません。なぜなら、Windowsはコンピュータの実際のメモリプールからの非アクティブデータをとにかく「ページアウト」するからです。 （あなたはDLL内の他のエントリポイントを公開するインポートライブラリを使用しない限り）すべての動的に呼び出されたサブルーチンはDLLとしてリンクされている必要があり
   2. は、リスト項目

   ダイナミック悪口を呼び出します。したがって、アプリケーションを何百ものサブルーチンで構成し、それらをすべて動的に呼び出す場合は、何百ものDLLを配布する必要があります。

5. DLLのバージョンを混在させることは可能です。これは、アプリケーションの配布とエンドユーザーによる更新プログラムの不適切なインストールの両方で問題になる可能性があります。
6. DLLの1つが見つからない場合、そのDLLを呼び出そうとする機能をユーザーが実行するまで、DLLについて知ることはできません。その時点で、この状況を処理しない限り、アプリケーションは異常終了します。
7. DLLを呼び出すと、そのDLLを取り消してからもう一度呼び出すと、キャンセルするとルーチンを再読み込みする必要があるため、より多くの入出力が発生します。これにより、より多くのディスクアクティビティが必要になるため、アプリケーションの処理速度が低下する可能性があります。 Windows環境では、Windowsはメモリ管理の面で優れているため、通常は不要です。
8. 同じサブルーチンに静的呼び出しと動的呼び出しを混在させて一致させると、ソフトウェアに複数の異なるバージョンが同時にメモリに存在することがあります。それがどれくらい楽しいのかデバッグしようとしているでしょうか？詳細情報については

それは多くの利点がありHere

Answer 4

は、以下を参照してください

あなたは小さな更新を行っている-if、ユーザーが完全なexeファイルをダウンロードする必要がdoesntの、彼らは唯一のいくつかのDLLをダウンロードする必要が - dllを使用している別のプログラムをコーディングしている場合、ユーザーはメモリを節約できます - プログラムが巨大になり、数分の構築時間があれば、すべてを再構築する必要はありませんあなたは変更を加えているだけで、変更されたDLLを再構築することができます

しかし、それはいくつかの否定的な視点があります。 - あなたのユーザーが（彼らは本当に愚かであれば）のdllを削除し、プログラムはもう -Without DLLを作業イマイチなぜだろうことができ、ユーザーはすぐにポータブル版

を構築することができますあなたのプロジェクトが巨大な場合（4MBのexeのように聞こえます）、私はプログラムを分割しますが、それが小さなプログラムならば、私はプログラムを分割しません。

Answer 5

私が開発しているアプリケーションでも同様のアプローチを採用していますが、主な理由は、アプリケーションのコンソールバージョンの開発を可能にすることです。そうすれば、XAML GUIを使用して、アプリケーションで1度に1つの操作を簡単に実行できます。その後、コンソールバージョンを使用して長時間実行/保守操作をスケジュールできます。どちらも同じモデルとビューモデルのレイヤーを使用しますが、明らかに異なるビューです。

MVVMの大きな利点の1つで、特にコンポーネントを別のプロジェクト/ライブラリに分割しているような気がするのです。

Answer 6

私たちは現在、特定のニッチ市場をターゲットにした大規模なアプリケーションに取り組んでいますが、多くのお客様は、ニーズに合わせてさまざまな機能を使用する小規模なアプリケーションを必要とします。単一のデータベース。このため、私たちのWpfアプリケーションは、これを行うことができる唯一の真の方法である多くの異なるアセンブリに分割されています。多くの点で、これらの追加ツールをほぼ新しく開発し、新しい開発の一部を作り、既存の開発を統合して、これらの新しいアプリケーションを素早くテストして、ほとんどテストされたコードを作成します。