1

今後の説明が十分に意味をなさない場合は、申し訳ありません。私はそれで有名ですが、別のことをしようとしています。

ユーザー定義のプラグインを利用するサービスを作成しています。共有アセンブリで定義されたインターフェイスを利用して、アセンブリをサービスのappdomainから除外して、それらを分離しようとしています。

私を殺しているのは、抽象基本クラスの使用です。一部のインターフェースのすべての実装に共通する機能があるため、抽象基本クラスは理にかなっています。抽象ベースがサービス アセンブリにある場合、それをサブクラス化するプラグインはすべて、そのアセンブリをサービスの appdomain にドラッグします。ただし、サービスが使用する抽象ベース (内部セッターとパブリック ゲッターを持つプロパティ) には内部メンバーがあるため、それを可能にするには、サービスと同じアセンブリにある必要があります。

私が望んでいることは不可能のようですが、それは私が間違ったアプローチを取っているからだとも信じています. 私は必死に、この演習で良いパターンとプラクティスをより有効に活用し、その過程で学習しようとしています。

4

3 に答える 3

0

おそらく必要なのは、インターフェースを実装し、派生クラスが継承できる抽象基本クラスを持つインターフェースです。この場合、インターフェースを使用して分離を維持しながら、実装用の抽象基本クラスを提供できます。これには、抽象基本クラスがオプションであるという利点もあります。

于 2009-12-06T19:21:18.993 に答える
0

（私とおそらく他の人の将来の参考のために）

これはやや無意味な演習であることがわかりました。

プラグインによって作成されたオブジェクトのプロキシが他のアプリケーション ドメインで使用可能になると、そのサービス定義の基本クラス内で内部的にサービスを利用するもの (コレクションに対するルックアップなど) は、サービス オブジェクトのコピーに対して動作します。私が提供しようとしているシングルトンではなく、プラグインのアプリドメインです。

複数のアプリドメインのクエストを放棄するか、内部で何かを放棄するかのどちらかだと思います。内部操作がない場合、基本クラスはサービスから分割できますが、他のすべての場合と同様に、サービスとやり取りする必要があります。

私は学ぶことを楽しんでいますが、途中で頭にぶつかるのが好きではありません.

于 2009-12-13T17:27:56.317 に答える
0

回避しようとしている問題がプラグイン アセンブリをサービス AppDomain にリークすることである場合、内部メンバーがあるかどうかに関係なく、その問題は発生しません。プラグイン ドメイン内でサービス アセンブリを使用できるようにする必要があるだけであり (その逆ではありません)、別のアセンブリではなくサービス アセンブリで共有型を定義する必要があります (実際に「内部」が必要な場合)。他のアセンブリ)。

PluginBaseServiceLib.dll で定義された抽象基本クラスがあるとします。次に、メイン サービスの AppDomain に次のようなコードを含めることができます。

// Create a new AppDomain for the plugin
AppDomain pluginDomain = AppDomain.CreateDomain("PluginDomain", null, new AppDomainSetup());

// Instantiate the plugin type (in the new AppDomain)
// Note: assumes that PluginBase is MarshalByRefObject
PluginBase plugin = (PluginBase)domain.CreateInstanceAndUnwrap("PluginLib", "PluginLib.PluginImp");

// Set any internal stuff now
plugin.InternalDetails = "...";
于 2009-12-06T19:34:53.463 に答える