抽象基类和appdomains

时间:2009-12-06 19:13:51

标签: c# .net appdomain abstract isolation

如果我即将发表的解释没有足够的意义,我现在道歉。我为此而闻名,尽管我试着这样做。

我正在编写一个使用用户定义插件的服务。我正在尝试隔离它们 - 通过使用共享程序集中定义的接口将它们的程序集保留在服务的appdomain之外。

让我感到害怕的是使用抽象基类。有些功能对于某些接口的所有实现都是通用的,因此抽象基类是有意义的。如果抽象基础在服务程序集中,那么子类化的任何插件都会将其程序集拖入服务的appdomain。但是,在服务使用的抽象基础(具有内部setter和公共getter的属性)中有内部成员,因此它需要与服务在同一个程序集中才能实现。

似乎我想要的是不可能的,但我也相信这是因为我采取了错误的做法。我正拼命想在这个练习中更好地利用好的模式和实践,并一路学习。

3 个答案:

答案 0 :(得分:0)

你可能想要的是一个带有抽象基类的接口,它实现了接口,派生类可以继承。在这种情况下,您可以使用接口维护您的分离,但仍然提供实现的抽象基类。这也具有抽象基类是可选的优点。

答案 1 :(得分:0)

如果您要避免的问题是将插件程序集泄漏到服务AppDomain中,那么无论您是否有内部成员,都不会遇到此问题。您只需要在插件域内提供服务程序集(而不是相反),您可能必须在服务程序集中定义共享类型而不是单独的程序集(如果确实需要“内部”)另一个集会)。

想象一下,您在ServiceLib.dll中定义了抽象基类PluginBase。然后,您可以在主服务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 = "...";

答案 2 :(得分:0)

(对于我和其他人未来的参考)

事实证明这是一个毫无意义的练习。

一旦插件创建的对象的代理在其他appdomains中可用,那个服务定义的基类中以内部方式使用服务的任何东西(比如对集合的查找),它都会对照副本插件的appdomain中的服务对象,而不是我试图提供的单例。

我认为我要放弃我的多appdomain任务或放弃在内部做任何事情。如果没有内部操作,基类可以从服务中拆分,但是它必须像其他所有操作一样与服务进行交互。

我喜欢学习,但我并不欣赏沿途的头部碰撞。