使用Simple Injector构建基于插件的应用程序

Question

我被赋予了编写技术规范（以及后来实现）的任务，该系统将构建在几个子模块上。子模块将部分并行开发，因此每次添加或更新插件时，我都希望避免重新启动整个系统。由于我已经在另一个项目中使用了Simple Injector，我计划在每个子模块中将它用于IoC。我不打算在将模块绑定在一起的核心中引入MEF（Managed Extensibility Framework）或MAF（Managed AddIn Framework），我的计划是看看Simple Injector是否也可用于处理模块。

我的计划是使用FileSystemWatcher来观察插件目录​​，当检测到更改时，要么使用Simple Injector，要么执行此操作，或者使用自己的解决方案。我已经阅读了讨论here，但我相信我的用例是不同的。

要求：

• 核心系统作为Windows服务运行，应该避免一直重启
• 每个模块负责内部编排需要完成的工作（可能很多，因此需要不重启所有内容）
• 整个系统是基于事件的。模块将事件发送到事件总线，以便其他模块可以根据事件做出反应（做它的事情）。但是，模块也可以定期进行。 F.X.一个模块侦听目录中的新文件，解析文件并将数据放入数据库。其他模块可能需要根据这些新数据执行某些操作。另一个模块进行一些定期计算。
• 所有模块都将共享一个通用接口IModule，它将使核心系统能够启动和停止（配置）模块，如果我找不到另一种方法，可能会附带注册事件总线的方法
• 在系统重启（f.x.服务器重启）时，核心当然应该能够获取所有现有模块

为了能够动态加载/重新加载程序集，我计划在单独的AppDomain中运行每个模块。

使用Simple Injector可以实现吗？还有其他想法吗？也许是我没有想过的事情。

Answer 1

这不是DI容器所促成的。他们只是组成对象图。在我看来，您需要运行独立的进程或应用程序域（否则将无法重新加载它们）。

这意味着DI容器将在该模块内的隔离域（即您的模块）内运行，您可以像使用它一样使用容器。这与Simple Injector没有什么不同。

Answer 2

因此，基于与史蒂文的通信，我决定寻找替代方案并与我的CTO交谈。这导致了一种完全不同的体系结构（微服务 - 可能实现为Azure功能）通过消息总线（Azure Service Bus）进行通信。这符合所有要求，并且（使用Azure功能）确保我们只在出现应该处理的事件时支付计算能力。