扩展/插件通信的体系结构

Question

一旦解决了加载插件的问题（在.NET中通过MEF），下一步要解决的是与它们的通信。简单的方法是实现一个接口并使用插件实现，但有时插件只需要扩展应用程序的工作方式，并且可能有很多扩展点。

我的问题是如何处理这些扩展点。我已经看到了不同的方法，但我不确定每个方法的优点和缺点，以及是否有更多更好的方法来实现这一目标：

• 事件：将静态事件添加到我们想要“扩展”的所有内容中。例如，如果我想为User类添加自定义验证，我可以添加一个OnValidation静态事件处理程序，并在构建它时从插件添加事件。
• 消息：有公共汽车和消息。插件可以订阅特定的消息，并在其他类发布该消息时执行操作。该消息应包含插件可以工作的上下文。在验证的情况下，逻辑层将发布UserValidation消息，插件将在收到消息时起作用。
• 接口：主机应用程序负责调用实现某些接口的所有插件，并为它们提供当前操作的上下文。在验证的情况下，插件可以使用Validate（对象上下文）方法实现IValidator或IUserValidator。

您是否曾使用过一种暴露的方法？哪一个最适合你？

在您提出要求之前，我们的应用程序是一个可扩展的核心（用户，rola和内容管理），以构建我们的客户端特定的以内容为中心的Web应用程序。一切都建立在ASP.NET MVC上。

Answer 1

您的设计决策的关键是分析并清楚地了解插件彼此之间的差异。

E.g。在处理静态事件时，您可能必须将每个事件定义为某种形式的令牌，枚举，对象等。为每个插件定义一组新事件自然会对您的整个设计起作用，特别是在松散耦合和重用。

如果您的插件非常不同，您可能会受益于拥有总线/消息传递架构，因为在这种情况下您可以引入插件可以订阅的域/类别的通信交换。即一系列事件和消息可以在某个兴趣域中。请注意，某个类别中的通信仍然可以使用静态事件，因此这两个备选方案并不相互排斥。

插件实现的直接接口是我体验最严格的插件架构方法。扩展插件接口通常意味着插件和提供程序的代码修改。你需要有一个坚实的通用界面，你知道你的应用程序可以存在很长一段时间。

通过将设计分解为两个方面 - 沟通渠道和协议，您可能更容易处理设计。静态事件处理是一个协议问题，而总线消息传递和直接接口是一个渠道问题。

一般来说，我会说协议从一开始就是最难设计的，因为你可能不会对一般或具体的绘制方式有一个坚实的感觉。

编辑： Lars在他的评论中提到了一个重点 - 如果您的平台支持异常，您可以在使用直接接口时集中大量错误处理，从而减轻插件处理错误的负担是通用的，可能超出他们的特定域（例如“插件加载错误”或“文件打开失败”）。但是，如果每次添加插件时都必须维护接口，这些好处似乎会消失。最糟糕的情况是接口开始变得不一致，因为你从一开始就没有意识到它们应该支持什么。当已经构思了大量插件时，重构整个界面设计并非易事。

Answer 2

我选择观察者模式。来自GOF：

  

定义一对多依赖关系   在一个对象之间   对象改变了状态   家属会得到通知和更新   自动。

也称为发布 - 订阅我建议它在您的示例中最接近匹配案例二。