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

Question

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

因为它似乎非常适合启用GUI的应用程序，我是否应该甚至将Prism用于此类应用程序？ 使用基类Microsoft.Practices.Prism.UnityExtensions.UnityBootstrapper时，我停止了编码，该类需要实现CreateShell()方法。 我有点希望它被命名为Run()类的名称。 我真的没有外壳，或者至少没有GUI外壳。 我是否读得很多，使用Prism而不用担心它具有潜在的冗余GUI功能是否有意义？ 我在为工作使用正确的工具吗？

Answer 1

正如史蒂文（Steven）的回答所述，Prism适用于客户应用程序。 Unity是依赖项注入容器的不错选择，但是我相信对于您的情况，使用Managed Extensibility Framework（MEF）或Managed Addin Framework（MAF）可能会更好。

如果在版本2.1之前的编译时知道类型映射，则主要使用Unity。

Managed Extensibility Framework是动态发现依赖项注入类型的理想选择。 请参见此处 ，了解它为从运行时程序集动态加载类型提供的选项数量。

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

Answer 2

我想您已经知道答案了。 Prism适用于客户应用程序。 即使您在服务器环境中正常工作，也会有很多框架在起作用。 您确实要使用IoC容器，并且已经为此使用Unity（默认情况下，Prism使用Unity）。 我的建议是抛弃Prism并开始使用Unity进行布线。 动态加载组件非常容易。 您不需要仅用于加载程序集的肿框架。