Architecture 棱镜模块和多个DI容器

我们的应用程序有几个窗口。目前，它们运行在单独的进程中，但这使得它们之间的通信非常困难（并且会增加JMS连接等资源）。其想法是将结构重构为单一流程，以简化通信和资源/服务共享

我想这样使用prism模块：

其想法是将每个windows“主程序”作为一个prism模块加载，然后每个模块可以根据需要初始化自己的DI容器（每个窗口由不同的团队生成）。模块不会对彼此的UI做出贡献，但它们可以通过主MEF容器共享服务。Main还可以加载一些模块可用的通用服务

通过将每个模块分离到它自己的DI容器，我试图防止模块之间的依赖地狱，并鼓励更严格地使用来自另一个模块的服务

这是可能的，还是DI容器相互碰撞（处于相同的过程中）

Prism中有什么东西会反对这种解决方案吗

我应该创建自己的迷你模块系统而不是prisms IModule吗

---

我们一直在研究的另一种可能性是将每个模块放在自己的AppDomain中。然而，这也有其自身的缺点（比如共享服务必须通过wcf等方式完成）。然而，单独的AppDomains将防止可能的DI容器冲突，并允许main在AppDomain出现故障时充当看门狗。是否有人拥有基于AppDomain的解决方案的经验？有没有什么问题没有在这里描述？

首先，在不同的进程上运行视图是个坏主意。 第二，prism的所有想法都是在一个进程和一个（！）容器中运行，以管理所有视图。 视图之间的通信通过服务和事件聚合完成。 它们之间不需要任何依赖关系。 我给大家举个例子： 你的应用程序代表一家商店。 您将有一个模块处理蔬菜（视图、视图模型、模型） 您将有一个模块处理乳制品（视图、视图模型、模型） 每个模块都需要使用soap服务来获取数据。 这将是一个共享服务，将注入两个模块。 你的第一个模块需要告诉所有关心的人所有蔬菜都卖了， 它将发送一个事件（聚合），需要知道的模块将侦听此类事件。 等等，模块之间的所有通信主要通过共享服务和事件聚合来完成。

---

希望我回答了你的问题

谢谢。你所描述的是棱镜的“正常”使用。我打算将其用作.net的特别osgi。该模块旨在作为一个比棱镜模块更大的概念使用，因为它是自己的解决方案，不同的模块由不同的团队生产。我想我会尝试基于appdomain和自定义mef模块的方法。我明白你的意思了。我认为你可以在没有应用程序域的情况下实现它。