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

时间:2018-06-08 10:46:26

标签: dependency-injection simple-injector plugin-architecture

我被赋予了编写技术规范(以及后来实现)的任务,该系统将构建在几个子模块上。子模块将部分并行开发,因此每次添加或更新插件时,我都希望避免重新启动整个系统。由于我已经在另一个项目中使用了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可以实现吗?还有其他想法吗?也许是我没想过的东西。

2 个答案:

答案 0 :(得分:1)

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

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

答案 1 :(得分:0)

因此,基于与史蒂文的往来,我决定考虑其他选择,并与我的首席技术官交谈。这导致了完全不同的体系结构(微服务-可能实现为Azure功能)通过消息总线(Azure服务总线)进行通信。这符合所有要求,并且(使用Azure功能)确保我们仅在发生应处理的事件时才为计算能力付费。