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 回答