没有接口(interface)的 C# 插件模式

Question

我遇到了实现一个插件模式的需要，它不适合我在其他地方看到的任何东西，我只是想知道我是不是以错误的方式看待它，或者是否有其他人遇到过同样的情况问题，可能有解决方案。

从本质上讲，我们有一个由核心组件和插入其中的多个模块组成的系统。一些模块依赖于其他模块，但需要不时删除或替换其中一些依赖项，我想尽可能避免重新编译。

该系统是定制的 CMS，模块是在 CMS 中提供功能的插件。例如，我们有一个评论模块和几个内容模块，例如新闻模块、博客模块等，它们可以包含评论功能。我的问题是有些客户可能不购买评论模块，所以我要么想办法防止依赖模块依赖于评论模块的存在，在某些情况下，可能需要迎合修改版本评论模块。

我们在运行时加载模块，目前，为了避免模块之间的相互依赖，我们使用核心 CMS 程序集中的接口(interface)来处理这个问题。我担心的是，为了避免每次创建可能存在依赖关系的新模块时都必须修改核心 CMS 程序集，我需要使用比接口(interface)和这些接口(interface)的实现更宽松的东西。

我正在考虑以下几点:

• 核心程序集包含一个允许注册和注销共享输入/输出消息的对象(例如“Comments.AddComment”或“Comments.ListComments”)
• 加载模块时，它们会通告所需的服务和服务 它们提供(例如，新闻模块需要“Comments.AddComment”消息，评论模块的任何变体都将提供“Comments.AddComment”消息)。
• 传递给这些消息的任何对象或数据都将从一个非常松散的基类继承或实现一个接口(interface)，该接口(interface)公开包含在核心程序集中的 IDictionary 类型的属性。或者，消息契约(Contract)只需要一个对象类型的参数，我将匿名对象从提供者/消费者传递给它们。

缺点显然是失去了强类型，但优点是我不依赖于严格的接口(interface)实现或要求包含在运行时可能不存在的模块。

插件通过反射加载，检查引用的程序集并寻找实现给定接口(interface)的类。 MEF 和动态类型不是一个选项，因为我仅限于 .NET 3.5。

任何人都可以提出更好的建议，或者可能是对这个问题的不同思考方式吗？

Answer 1

你是对的，如果你在核心应用程序中使用基类或接口(interface)，那么你需要重建应用程序和所有使用该类/接口(interface)的插件(如果它发生变化)。所以你对此能做些什么？这里有一些您可以混合搭配的想法(不一定是好的，但它们可能会激发一些想法)...

• 将接口(interface)放在单独的共享程序集中，因此如果接口(interface)发生变化，您至少不需要重新编译核心应用。

• 不要更改您的任何界面 - 让它们保持不变。取而代之的是对它们进行“版本化”，因此如果你想更改接口(interface)，你可以保留旧接口(interface)，只公开一个扩展或替换旧 API 的全新接口(interface)。这允许您逐渐弃用旧插件，而不是强制要求立即进行全局重建。这确实有点束缚你的手，因为它需要对所有旧接口(interface)的完全向后兼容性支持，至少在你知道你的所有客户都已经转移到他们所有程序集的更新版本之前。但是您可以将此与不太频繁的“重新安装所有内容”版本结合使用，在这种情况下您会破坏向后兼容性，清除失效接口(interface)并升级所有客户端程序集。

• 寻找所有插件都不需要接口(interface)的某些部分的接口(interface)，并将一些接口(interface)分解为几个更简单的接口(interface)，以减少每个接口(interface)的依赖性/变动。

• 正如您所建议的那样，将接口(interface)转换为运行时注册/发现方法，以最大程度地减少接口(interface)流失。您的接口(interface)越灵活和通用，就越容易在不引入重大更改的情况下扩展它们。例如，将数据/命令序列化为字符串格式、字典或 XML 并以该形式传递，而不是调用显式接口(interface)。像 XML 或名称 + 值对字典这样的数据驱动方法比接口(interface)更容易扩展，因此您可以开始支持新元素/属性，同时轻松地为向您传递旧格式的客户端保持向后兼容性。代替 PostMessage(msg) + PostComment(msg)，您可以将接口(interface)通用化为采用类型参数的单个方法:PostData("Message", msg) 和 PostData("Comment", msg) - 这样很容易支持新的无需定义新接口(interface)的类型。

• 如果可能，请尝试定义预期预期 future 功能的接口(interface)。因此，如果您认为有一天您可能会添加 RSS 功能，那么请考虑它可能如何工作，插入一个界面，但不要为其提供任何支持。然后，如果您最终开始添加 RSS 插件，它已经有一个定义的 API 可以插入。当然，这只有在您定义了足够灵活的接口(interface)以便系统在实现时实际可以使用它们时才有效!

• 或者在某些情况下，您可以将依赖插件发送给所有客户，并使用许可系统来启用或禁用他们的功能。然后，您的插件可以相互依赖，但您的客户无法使用这些设施，除非他们已经购买了它们。