C# Microsoft Prism是否适合开发非GUI模块化实时服务器？

我正在开发一个服务器端应用程序，它应该根据模块是否作为程序集存在，在启动时动态加载模块。我以前也做过类似的事情，但这次是生产代码，我想使用框架进行模块化和实例化（使用IoC容器）。我最初发现微软的Prism（带Unity）是一个适合做这件事的框架，但随着我实现初始化和引导，我越来越担心。服务器将没有自己的GUI，可能在以后作为windows服务运行。（同时，我正在将其开发为一个简单的控制台应用程序。）将开发各种客户端（每个模块大约一个客户端应用程序），以便通过WCF与服务器交互

---

我是否应该为这样的应用程序使用Prism，因为它似乎非常适合支持GUI的应用程序？在使用基类Microsoft.Practices.Prism.UnityExtensions.UnityBootTrapper时，我停止了编码，该基类需要实现

CreateShell（）

方法。我有点希望它被命名为

Run（）

或类似的名称。我没有真正的shell，或者至少没有GUI shell。我读了很多关于这方面的内容了吗？使用Prism而不用担心它有潜在的冗余GUI功能有意义吗？我是否使用了适合这份工作的工具？

我想你已经知道答案了。Prism用于客户端应用程序。即使您在服务器环境中实现了这一点，也会有很多框架挡住了您的去路。您确实希望使用IoC容器，并且已经为此使用了Unity（Prism默认使用Unity）。我的建议是，抛弃棱镜，开始使用Unity进行布线。动态加载程序集非常简单。您不需要一个臃肿的框架来加载程序集。

正如Steven在回答中所述，Prism是为客户端应用程序设计的。Unity是依赖注入容器的一个很好的选择，但是我相信对于您的情况，您可能会更好地使用或

Unity主要用于编译时已知类型映射的情况，在版本2.1之前，动态类型注册没有现成的支持

托管可扩展性框架非常适合动态发现依赖项注入的类型。有关它为从运行时程序集动态加载类型提供的选项数量，请参见

---

托管加载项框架是.NET Framework的一部分。自.NET 3.5以来，它最大的功能之一是程序集隔离，程序集可以加载到单独的应用程序域甚至进程中，然后仍然可以使用。这对于第三方加载项来说是非常好的，如果它们有bug和崩溃，它们不会让您的应用程序随之崩溃。

谢谢@Steven，我想您是对的。我将扮演我自己的程序集/模块加载器的角色，并使用Unity进行IoC管理。再次谢谢。谢谢，我会考虑的。也许两种方法都可以尝试，看看我最喜欢哪一种。这听起来像是一种方法，我还应该提到，没有什么可以阻止您对自己的类型使用Unity，对动态加载的程序集使用MAF/MEF。