c# - 在插件框架中使用抽象类作为契约

Question

抽象类可以用作“主机”和“插件”之间的契约对象吗？这个想法是插件继承了契约(我们称之为适配器)。我们还了解到框架中的所有参与者都必须继承 MarshalByRefObject (MBRO)。所以，这就是我们的想法 -

主持人:

class Host : MarshalByRefObject
{
}

契约(Contract):

public abstract class PluginAdapter : MarshalByRefObject
{
}

插件:

class myPlugin : PluginAdapter
{
}

这三个都存在于单独的 asm 中。我们的 Host 会为每个插件创建一个新的 AppDomain，PluginAdapter 的创建如下:

{
    ObjectHandle instHandle = Activator.CreateInstance(
    newDomain, data.Assembly.FullName, data.EntryPoint.FullName);

    PluginAdapter adapter = (PluginAdapter)instHandle.Unwrap();
}

编辑:其中data 是myPlugin 的具体类型。

我们想知道这个框架的实现是否可行。我们已经看到文章使用接口(interface) (IPlugin) 进行插件派生，并使用具体类作为契约。这些文章还会说可以使用抽象类，但没有给出该实现的示例。是否要求契约是一个具体的类？

编辑:在这个例子中，Richard Blewett - C# Reflection - 他使用了一个更简单的实现:

契约(Contract):

public interface IPlugIn  
{  
    // do stuff  
}

插件:

public class PlugIn : MarshalByRefObject, IPlugIn  
{  
}

现在，如果使用抽象类作为契约，Plugin 不能同时继承契约和 MBRO。那么，什么才是可扩展插件框架的最佳实现。即使最初我们是为单机操作开发的，我们是否应该继续实现远程处理？预计该项目将分布在网络中，也可能分布在 Internet 上。我们只是还没有实现 Tcp，因为我们正在尝试完全理解和操作插件​​框架的基础知识。

使用环回在单台机器上实现 Tcp 远程处理是否有意义？

Answer 1

抽象类是更好的选择，恕我直言。这主要是因为接口(interface)更难版本化。 This blog post描述了如果您不使用基类，您可能会发现自己遇到的问题。这条规则不仅适用于插件，顺便说一句。

关于您的设计...

插件不应该扩展 MBRO。您应该使用您的主机(它应该扩展 MBRO)将所有调用编码到您的插件，包括处理插件事件。如果您尝试将它们拉过来并使用它们的代理，则很容易无意中将插件 DLL 加载到您的主应用程序域中。

例如，如果插件为其方法之一返回 IEnumerable，它可能会返回在插件程序集中定义的 IEnumerable 的实现。如果那不扩展 MBRO，主应用程序域将不得不加载插件程序集。

---

我在这里上传了三个处理 appdomains 的项目:

http://cid-f8be9de57b85cc35.skydrive.live.com/self.aspx/Public/NET%20AppDomain%20Tests/appdomaintests.zip

一个是跨应用域使用回调，第二个是跨应用域事件处理，第三个是插件示例。

在插件示例中，一个应用程序定义了一个插件接口(interface)(它是一个演示，而不是最佳实践!)和一个插件主机。该应用程序从磁盘加载原始插件程序集，并通过加载它的插件主机代理将其传递到插件应用程序域。然后插件宿主实例化插件并使用它。但是，当主机将插件程序集中定义的类型返回到应用程序应用程序域时，插件程序集将加载到主应用程序域中，从而使整个插件变得毫无意义。

避免这种情况的最佳方法是为未标记为可序列化且未扩展 MBRO 的插件提供一个抽象基类，并且仅将您定义的基元或密封类型从插件域的边界带回。

注意:项目都是 4.0 RC。你需要这个或以上来运行它们。否则，您将不得不手动编辑项目文件或重建它们以使其在 b2 或 2008 中运行。