2009-04-24 13 views
7

私はかなりリフレクションが新しく、私は(2番目の)AppDomainを何に使うのだろうかと思いましたか?ビジネスアプリケーションにはどのような実用的なアプリケーションがありますか?いつAppDomainを使用しますか?

答えて

9

多くの用途があります。セカンダリAppDomainは、OSがプロセスを提供する分離と同様の分離度を提供できます。

「プラグイン」DLLを動的にロードするために使用した実用例の1つです。私は、メイン実行可能ファイルの起動時にDLLのディレクトリをスキャンし、ロードしてそのタイプをチェックして、特定のインタフェース(つまり、プラグインの契約)が実装されているかどうかを確認したかったのです。セカンダリAppDomainを作成せずに、探しているインターフェイスを実装する型を持たないDLL /アセンブリをアンロードする方法はありません。余分なアセンブリや型などをプロセスに持ち込むのではなく、セカンダリAppDomainを作成し、そこにアセンブリを読み込んで型を調べることができます。完了したら、セカンダリAppDomainを取り除くことができ、したがってあなたのタイプを取り除くことができます。

+0

あなたが探していたDLLを見つけたら、これらのプラグインをメインのAppDomainにロードしましたか?または、彼らは常に2番目のAppDomainに滞在しましたか? – Steven

+1

いいえ、それらを「プライマリ」ドメインにロードしたので、コールを前後にマーシャルする必要はありませんでした。私たちが使用した別のエッジケースの状況は、複数の論理サービスを独自のAppDomainsにロードしたサービスにありました。正直なところ、それは私の決断ではなく、別のサービスを作っただけですべきだと思っていました。 –

2

私が追加のAppDomainsを避ける時間の99%。これらは本質的に別個のプロセスです。あるドメインから別のドメインにデータをマーシャリングして、複雑さとパフォーマンスの問題を追加する必要があります。

AppDomainを使用して、アセンブリがAppDomainにロードされた後にアンロードできないという問題を回避しようとしました。したがって、2つ目のAppDomainを作成して、ダイナミックアセンブリを読み込み、完全なAppDomainをアンロードして、アセンブリに関連付けられたメモリを解放することができます。

&アンロードアセンブリを動的にロードする必要がなければ、実際にはそれほど心配する価値はありません。

+1

プラグインモデルのように、型検査のためのアセンブリをロードするために使用することは、それらのための大きな用途です。発生したのは少し余分な起動時間です。 –

+0

合意しましたが、ある時点でアンロードする場合にのみ、そうでなければ違いはありません。 また、私はそれらが必要とされることを期待しませんでした。 – Steven

+0

異なるAppDomainsにはプロセスと同じ分離がありません。プロセスメモリ空間を共有します。 –

0

AppDomainsは、シングルトンのインスタンスを複数持つ必要がある場合に便利です。たとえば、あるデバイスへの通信プロトコルを実装するアセンブリがあり、このアセンブリではシングルトンが使用されます。このクラスの複数のインスタンスをインスタンス化し(複数のデバイスと通信する)、インスタンスが互いに干渉しないようにするには、AppDomainsがこの目的に最適です。

しかし、AppDomainの境界を越えて通信するためには多くの作業が必要になるため、プログラミングが難しくなります。

関連する問題