私はリフレクションにかなり慣れていないので、(2番目の)AppDomainを何に使用するのだろうと思っていましたか? ビジネスアプリケーションでは、どのような実用的なアプリケーションがありますか?
3 に答える
多くの用途があります。セカンダリ AppDomain は、OS がプロセスに提供する分離と同様の程度の分離を提供できます。
私が実際に使用した用途の 1 つは、「プラグイン」DLL を動的にロードすることです。メインの実行可能ファイルの起動時にディレクトリをスキャンして DLL を探し、それらをロードし、それらのタイプをチェックして、特定のインターフェイス (つまり、プラグインのコントラクト) が実装されているかどうかを確認する機能をサポートしたいと考えました。セカンダリ AppDomain を作成しないと、必要なインターフェイスを実装する型を持たない可能性がある DLL/アセンブリをアンロードする方法がありません。プロセスで余分なアセンブリや型などを持ち歩くのではなく、セカンダリ AppDomain を作成し、そこにアセンブリを読み込んで型を調べることができます。完了したら、セカンダリ AppDomain を削除して、型を削除できます。
99% の確率で、AppDomain を追加することは避けます。これらは本質的に別個のプロセスです。あるドメインから別のドメインにデータをマーシャリングする必要があり、複雑さとパフォーマンスの問題が追加されます。
AppDomains を使用して、一度 AppDomain に読み込まれたアセンブリをアンロードできないという問題を回避しようとする人がいます。したがって、動的アセンブリをロードできる 2 つ目の AppDomain を作成し、完全な AppDomain をアンロードして、アセンブリに関連付けられているメモリを解放します。
アセンブリを動的にロードおよびアンロードする必要がない限り、心配する必要はありません。
AppDomains は、シングルトンの複数のインスタンスが必要な場合に役立ちます。たとえば、あるデバイスに通信プロトコルを実装するアセンブリがあり、このアセンブリがシングルトンを使用しているとします。(複数のデバイスと通信するために) このクラスの複数のインスタンスをインスタンス化し、インスタンスが互いに干渉しないようにする場合、AppDomains はこの目的に最適です。
ただし、AppDomain の境界を越えて通信するためにより多くの作業を行う必要があるため、プログラミングはより困難になります。