【问题标题】:Methods for composing configuration for composite applications (eg PRISM, MEF)组合应用程序(例如 PRISM、MEF)的配置组合方法
【发布时间】:2011-04-01 13:48:48
【问题描述】:

PRISM 和 MEF 等框架可以非常轻松地使用多个可组合的组件来设计复杂的应用程序。一个常见的例子是插件架构,其中应用程序外壳可以使用插件 UI 组件动态重新配置(例如,通过将 DLL 放入 Plug-ins 目录)。

这一切都很好,但是正如 Vaccano 在 Can Prism be modular when calling webservices? 中发现的那样,在某些情况下,每个单独的插件都需要自己的一组配置 - WCF 绑定是一个典型示例,但还有许多其他场景(日志记录、数据库连接等)具有类似需求。

所以,在我看来,我们的选择是:

  • 所有配置都进入 shell 应用程序的 App.config(正如 Vaccano 所说,这破坏了该模型的整个封装和部署优势),或者
  • 每个插件程序集都使用定制机制进行配置(例如嵌入式资源),然后使用它来动态配置 WCF 服务,例如(最好的情况是混乱且耗时,最坏的情况可能无法)

这些选项都不是理想的,但它们是解决方法。但是,理想的情况是每个插件 DLL 都具有自包含配置(例如嵌入式资源文件)或 Xxx.dll.config 文件,并将这些 XML 配置片段中的每一个合并到 App.config 配置中shell 应用程序在运行时动态地运行。这让人想起 Machine.configApp.config 文件合并的方式。

因此,我的问题是:是否有人遇到过任何现有的框架或技术,可用于将复合配置文件动态合并到容器应用程序的进程内配置中? 我很惊讶没有将其视为 PRISM 或 MEF 的一部分,因此如果我遗漏了一些明显的东西,我会稍微谨慎地发布这个问题 - 如果是这样,请安静地发布相关链接 :) p>

【问题讨论】:

    标签: c# .net configuration prism mef


    【解决方案1】:

    我们遇到了同样的问题。我也没有找到解决办法。

    这是我看到人们做的(或者我们已经做过的)两件事:

    手动服务端点注册

    创建一个应用程序服务注册表,说明如何从 T 创建 ChannelFactory。每个模块都可以通过调用 RegisterService<T> 在 IModule Initialize 中对此做出贡献,并且该模块的所有从属视图都可以从中获取它们的通道工厂:

    public interface IServiceRegistry
    {
         void RegisterService<T>(ServiceEndpoint ep);
         ChannelFactory<T> GetService<T>();
    }
    

    当然,您可以只返回T,而不是在这里返回ChannelFactory&lt;T&gt;(买主警告)。 View/ViewModels 将简单地请求 IServiceRegistry 作为依赖项并以这种方式获取他们的服务代理。这也为编写单元测试时提供了一个方便的隔离位置。

    嵌入式配置

    一个约定系统与上述大致相同,但基于嵌入在 DLL 中的配置(如您所建议的)并利用命名配置。您会以与上述相同的方式使用它,但体验会略有不同。我们使用 DLL 中嵌入的约定“Endpoints.config”并从中读取。

    public interface IServiceChannelFactoryFactory //I'm terrible at naming
    {
        //This is much like the generated concrete class when you use "Add Service Reference"
        //Except there is no method with an empty parameter
        ChannelFactory<T> GetService<T>(string endpointName);
    }
    

    我们的“Endpoints.config”每个 endpointName 有多个端点,并添加了使该端点对环境(DEV、QA、Staging、Production)唯一的属性。我不知道你是否担心,但这是放置这种配置的一个方便的地方。

    两者都有效。令我惊讶的是,我没有看到更多的人谈论这个。好问题。

    【讨论】:

    • +1 为解决 WCF 配置问题提供了一些不错的选择,但真的希望有一个通用的解决方案 :)
    • @Chris Ballard:我在您问题的“现有技术”(我们采用的技术)条款下回答了这个问题。不过,我也想要一个通用的解决方案。
    • 是的,我意识到 - 非常感谢,尤其是多环境选项 - 如果可以的话,我会给你另一个 +1
    【解决方案2】:

    来自模式与实践的Composite Services guidance 项目(为您带来 Prism 的同一团队)提供了服务发现、组合和集成的设计和实现模式。

    关于动态配置合并,看一下我们在 Enterprise Library 5.0 中对complex config scenarios 的实现。它不是通用的,只专注于企业库配置,但您仍然可以检查源代码。

    【讨论】:

      【解决方案3】:

      对于 Windows/WPF 应用程序,您可以通过创建自定义设置提供程序来完成此操作 - 这是您构建的插入 .net 配置系统的类。

      理论上,您可以将设置放入特定于模块的配置文件中。您将构建一个设置提供程序,该提供程序知道如何在运行时查找这些特定于模块的文件,并提供设置。由于它位于堆栈中的配置使用者“下方”,因此 WCF 或其他技术不需要知道任何特殊知识即可使用它。唯一的缺点是 Silverlight 似乎不支持它。

      这里是实现代码项目文章的链接:http://www.codeproject.com/KB/vb/CustomSettingsProvider.aspx

      这里是 MSDN 文档的链接:http://msdn.microsoft.com/en-us/library/system.configuration.settingsprovider.aspx

      【讨论】:

      • 也许我错过了一个微妙之处——但这似乎只是为了替换 appSettings,而不是任意复杂的配置部分(例如 WCF、log4net 等)?
      • 不——你可能是对的。我没有尝试用它来替换任意复杂的部分。
      猜你喜欢
      • 1970-01-01
      • 2011-03-24
      • 1970-01-01
      • 1970-01-01
      • 2011-11-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多