3

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

我是否应该将 Prism 用于这样的应用程序，因为它似乎非常适合支持 GUI 的应用程序？Microsoft.Practices.Prism.UnityExtensions.UnityBootstrapper在使用需要实现方法的基类时，我停止了编码CreateShell()。我有点期望它被命名为类似Run()或类似的东西。我真的没有外壳，或者至少没有 GUI 外壳。我是否对此进行了大量阅读，使用 Prism 是否有意义，而不必担心它具有潜在的冗余 GUI 功能？我是否使用了正确的工具来完成这项工作？

4

2 回答 2

3

如 Steven 的回答所述，Prism 旨在用于客户端应用程序。Unity 是依赖注入容器的不错选择，但是我相信对于您的情况，使用Managed Extensibility Framework (MEF)或Managed Addin framework (MAF)可能会更好。

Unity 主要用于在编译时已知类型映射时使用，在 2.1 版之前，没有对动态类型注册的开箱即用支持。

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

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

于 2013-08-21T19:30:40.180 回答
3

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

于 2013-08-21T11:26:51.040 回答