6

アプリケーションにデフォルトで DLL をロードさせるのではなく、動的に DLL をロードする利点を探しています。

4

6 に答える 6

4

1 つの利点は、プラグイン アーキテクチャをサポートすることです。

たとえば、スケジュールに基づいてさまざまな種類のタスクを実行するサービスを作成するとします。これらのタスクが行っていることは、適切なタイミングでそれらを開始するためだけに存在するコア サービスと実際には関係ありません。また、将来、他のタイプのタスクを実行するためのサポートを追加したいと考える可能性が高くなります (または別の開発者がそうするかもしれません)。そのシナリオでは、プラグイン アプローチを実装することで、コア サービスとは独立してコーディングできる (インターフェイスで互換性のある) dll をさらに追加できます。そのため、新しいタスクのサポートを追加しても、サービス全体の新しいビルド/デプロイは必要ありません。特定のタスクを変更する必要がある場合は、その dll だけを再デプロイしてから自動的に取得する必要があります。

また、他の開発者がサービス自体に関心を持たないようにする必要もあります。実装するインターフェイスを理解すれば、それを利用できるようになるだけです。

于 2010-02-10T11:34:03.907 に答える
2

このアーキテクチャを処理アプリケーションに使用して、さまざまな顧客が必要とする違いを処理します。各DLLは同様の構造を持ち、同じインターフェイスとエントリメソッド「Process（）」を実装します。顧客に基づいてロードするクラスと、呼び出す必要のあるプロセス以外のメソッドがあるかどうかを定義するXMLファイルがあります。トランザクション数が非常に多くなるまで、パフォーマンスは問題になりません。

于 2010-02-10T12:28:05.583 に答える
1

必要なDLLのみをロードする場合は、アプリケーションの起動時間が速くなるはずです。

于 2010-02-10T12:28:40.717 に答える
1

あなたの質問はC＃/。NETに関するものなので、この世界ではダイナミックDLLのロードには高度なプログラミングスキルが必要です。これにより、ダイナミックDLLロードの潜在的な利点をすべて補うことができます。あなたは単にたくさんの「低レベル」コードを書かなければならないでしょう。

C ++ / Win32では、このDLLに古いオペレーティングシステムでは使用できない新しいAPI関数がある場合、DLLを動的にロードする必要があることがよくあります。この場合、実行時にこのAPIの可用性を確保する必要があります。レガシーオペレーティングシステムでアプリケーションの読み込みエラーが発生するため、このDLLに対してリンクすることはできません。

前述のように、プラグインベースの環境でもいくつかの利点があります。この場合、DLLを動的にロードすると、リソースをより細かく制御できます。基本的に、COMはダイナミックDLLハンドリングの良い例です。

于 2010-02-10T11:32:38.740 に答える
1

共有オブジェクトを動的にロードすることは、実行中のアプリケーションに対してアドホックにプラグインを許可するメカニズムです。プラグインがなければ、モジュラー アプリケーションはリンク時またはコンパイル時にまとめる必要があります (nginx のコードを見てください)。

于 2010-02-10T11:19:50.070 に答える
0

DLL を動的にロードするもう 1 つの理由は、堅牢性のためです。

AppDomain と呼ばれるものに DLL を読み込むことができます。Appdomain は、基本的には、(DLL の一部または EXE 全体のいずれか) を入れて、アプリケーション内で分離して実行できるサンド ボックス コンテナーです。

AppDomain に含まれる型を呼び出さない限り、アプリケーションと対話する方法はありません。

そのため、危険なサード パーティの DLL や、ソース コードを持っていない DLL がある場合は、それを AppDomain にロードして、メインのアプリケーション フローから分離しておくことができます。

最終的に、サード パーティの DLL が wobbly をスローした場合、影響を受けるのはアプリケーション ドメインだけであり、アプリケーション全体には影響しません。

于 2012-12-03T15:58:43.313 に答える