1

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

今、私はこのようにアプリケーションを複数に分割しました

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

ビューモデルをJIMS.exeからJIMS.ViewModel.dllに削除して、さらに2つのdllを追加することをさらに考えています。

今私の質問は、これは単一のEXEを複数のdllに吐き出す良い方法ですか?

これのメリットとデメリットを教えてください。

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

前もって感謝します。

4

6 に答える 6

4

言及されているのを見たことがないので、私はチップを入れます。

私の経験では、C# でこのアプローチを使用する主な理由exchangeabilityは、システムの一部を簡単に交換できるようにするためです。

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

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

于 2012-05-11T08:45:35.890 に答える
0

私が開発しているアプリケーションでも同様のアプローチを採用していますが、私にとっての主な理由は、アプリのコンソールバージョンの開発を可能にすることです。そうすれば、XAML GUIを使用して、アプリで一度に1つずつ簡単な操作を提供し、コンソールバージョンを使用してより長い実行/メンテナンス操作をスケジュールできます。これらは両方とも同じモデルとビューモデルレイヤーを使用しますが、明らかに異なる「ビュー」です。

私にとって、これはMVVMの大きなメリットの1つであると感じています。特に、コンポーネントを個別のプロジェクト/ライブラリに分割している場合はそうです。

于 2012-05-11T12:34:15.243 に答える
0

これらの dll を他のプロジェクトで個別に使用する場合は、それらを分割してもかまいません。そうしないと、どのような利点がありますか? あなたのアプリケーションについてはわかりませんが、コントロールを作成している場合、他の開発者が使用する場合、またはアプリケーションを他のアプリケーションに統合する場合、dll を個別に管理するのは難しい作業になる可能性があります。あなたの最後の意見についてはよくわかりません。私はそれに対するコミュニティの入力を見たいです

于 2012-05-11T05:56:12.133 に答える
0

多くの利点があります。

-小規模な更新を行う場合、ユーザーは完全な exe ファイルをダウンロードする必要はなく、いくつかの dll をダウンロードするだけで済みます。これらのファイルは、非常に小さいものです -DLL を使用する別のプログラムをコーディングしている場合、ユーザーは保存できますメモリ -プログラムが巨大になり、ビルド時間が数分かかる場合、すべてを再構築する必要はありません。変更を加えている場合は、変更された dll を再度構築するだけです。

しかし、それにはいくつかの否定的な見方があります: -ユーザーは dll を削除する可能性があり (本当に愚かな場合)、なぜプログラムが機能しなくなったのか不思議に思うかもしれません - dll がなければ、ユーザーは移植可能なバージョンをすばやく構築できます

プロジェクトが巨大な場合 (4MB exe のように聞こえます)、プログラムを分割しますが、小さなプログラムの場合はプログラムを分割しません。

于 2012-05-11T06:03:18.923 に答える
-1

アプリケーションを複数の dll に分割するとよいでしょう。これにより、プロジェクトの管理が容易になり、機能の追加/削除が容易になり、既存の dll を使用して完全に新しいアプリケーションを作成することが容易になります。アプリケーションには動的リンクの方が適していると思います.....

動的呼び出しの良い点

  1. サブルーチンで何かを変更した場合、アプリケーションを再リンクする必要はありません。サブルーチン DLL のみを再リンクする必要があります。
  2. このサブルーチンを呼び出すすべての実行可能ファイルは、同じ DLL を共有します。コードとデータの両方。アプリケーションは、動的に呼び出されたサブルーチンのコピーを 1 つしかロードしないため、使用するメモリが少なくなります。
  3. 動的に呼び出されたサブルーチンに含まれる値の変更は、それを使用するすべての DLL で利用できます。これは、すべての DLL がサブルーチンの同じコピーを共有しているためです。
  4. サブルーチンを CANCEL することにより、動的に呼び出されたサブルーチンが使用していたメモリを解放できます。ただし、Windows は非アクティブなデータをコンピュータの実メモリ プールから「ページ アウト」するため、これは一般に 32 ビット Windows 仮想メモリ環境ではあまり役に立ちません。
  5. リスト項目

動的呼び出しの悪い点

  1. 動的に呼び出されるすべてのサブルーチンは、DLL としてリンクする必要があります (インポート ライブラリを使用して DLL 内の他のエントリ ポイントを公開する場合を除く)。したがって、アプリケーションが数百のサブルーチンで構成され、それらがすべて動的に呼び出される場合、数百の DLL を配布する必要があります。
  2. DLL のバージョンを混在させることができます。これは、アプリケーションを配布する場合と、エンド ユーザーが更新プログラムを不適切にインストールする場合の両方で問題になる可能性があります。
  3. DLL の 1 つが見つからない場合、ユーザーがその DLL を呼び出そうとする何らかの機能を実行するまで、そのことを認識できない場合があります。その時点で、この状況を処理しない限り、アプリケーションは異常終了します。
  4. DLL を CALL し、CANCEL してから再度 CALL すると、CANCEL するとルーチンを再ロードする必要があるため、より多くの I/O が発生します。これにより、より多くのディスク アクティビティが必要になるため、アプリケーションの速度が低下する可能性があります。繰り返しますが、Windows 環境では、Windows はメモリ管理の優れた仕事を行うため、これは通常不要です。
  5. 同じサブルーチンへの静的呼び出しと動的呼び出しを組み合わせて使用​​すると、ソフトウェアのメモリ内に複数の異なるバージョンが同時に存在する可能性があります。その混乱をデバッグしようとしているのがどれだけ楽しいと思いますか?

詳細については、こちらを参照してください

于 2012-05-11T05:56:36.800 に答える