在应用程序的不同插件之间进行通信的最佳c#架构/模式

我目前正在从头开始设计一个系统，我们遇到了一个架构设计场景，我不确定解决这个问题的最佳方法，但我相信其他人已经解决了，甚至可能有一个模式

到目前为止的故事：

我们有一个多tenent网站，我们在其中实现各种插件功能，我们的客户将选择他们希望在其应用程序中使用的插件。每个插件都可以有用户可以添加到页面的各种“小部件”。（例如，类似于Android应用程序通常附带小部件，您可以将其添加到主屏幕）

插件可以依赖于其他插件来启用（例如，电子商务插件需要支付插件）。此外，插件还可以使用其他插件来增强其功能（例如博客插件可以选择使用评论插件，也可以使用电子商务产品的评论）

尽可能地，我们希望每个插件都是独立的，有一个非常精简的plublic接口。我们相信这种关注点的分离将为我们提供整个系统的最佳长期灵活性和可维护性

问题是：

当我们开始布局我们目前知道的所有插件（更不用说未来的需求），以及它们的依赖性和可能与其他插件的关系时，它开始对疯狂的蜘蛛网产生强烈的反应。我们也开始看到一些循环引用

例如，导航插件需要知道网站上有哪些页面。但您也可以向页面添加导航小部件

部分/潜在解决方案：

我们认为每个插件应该完全独立于其他插件，但可以通过消息从其他插件获取信息并与之通信。这些消息可以分为两种基本类型

• 从其他插件请求信息（请求/响应消息）
• 事件通知（事件消息）

这两种消息类型都是非常简单的DTO类型类——它们不应该包含任何业务逻辑——只是一些其他服务处理请求和提供响应所需的信息

我已经模拟了几个插件的一个非常简化的版本，我们看到它们与其他插件交互的解决方案是：

在这个图中，导航、页面、搜索和其他插件彼此都不了解。但是他们会知道可用的消息以及ProcessMessages接口

例如请求/响应消息

导航和其他插件会知道，如果它发送一个GetPagesRequest来处理消息，它将返回一个PagesResponse，其中包含他们需要的所有信息。（导航/其他插件需要立即响应GetPagesRequest。）

导航和其他插件对页面插件一无所知

请求/响应消息要求

引发请求消息的插件总是（通常？）希望立即收到响应消息

只有1个服务知道如何处理请求消息，并提供将被传递回调用插件的响应消息

事件消息

当用户在页面插件中更新页面的url时，插件将向ProcessMessages发送一条PageUrlUpdated消息。导航和其他插件随后将使用PageUrlUpdated消息并执行任何需要的操作

事件消息要求

引发事件的插件永远不会期待响应。 0-许多插件可能会使用给定的消息

（技术说明：对于事件消息，我们将把它们发送到MassTransit和RabbitMQ-然后每个消息有1-n个使用者）

问题

从我们制作的一些草图来看，上述想法似乎可行，并且系统不同元素之间的相互依赖性要小得多。但我不知道设计模式或建筑结构的名称——或者我是否完全走错了方向。我希望有人能给我指出正确的解决方案——一些好的文档和示例会非常好。（试图避免重新发明轮子——而现有的模式可能更稳健、更成功）

对于请求消息，我们设想了从请求消息到处理消息的具体插件/服务的某种StructureMap-ish映射。再一次——我确信这已经被解决了，而且有一个模式，或者我们完全走错了方向，有更好的解决方案

非常感谢您的任何帮助和想法 萨恩

---

PS-我在一个公共项目中也会有一个IWidget，它具有一些基本属性-因此Pages插件可以请求实现IWidget的所有类添加到一个页面

您的问题有很多不同的方法；但我可能会建议采用面向服务的体系结构。主要是因为它可以以一种非常快速和敏捷的方式向业务屈服。此体系结构提供了许多好处：

• 轻量级
• 敏捷的
• 代码可重用性

然而，它确实带来了一系列可能需要克服的障碍，例如：

• 互操作性
• 保安
• 演出
• 坚持

因此，执行其中一些决议可能会缓解这一问题。然而，这需要你对此事有所了解。因为这个架构是敏捷的，但是每件事都有一定程度的暴露性。另外，实例化多个实例会怎么样

这些都是你必须确定的潜在项目

我个人要做的是找到业务的真正核心——而不是项目；但是生意。然后确定哪种方法最适合实现

         Ask not the Elves for counsel, as they both say yes and no.