4

在我当前的解决方案中，我有 18 个项目，其中大多数都有自己的配置文件（app.config 或 web.config）。每个项目使用单个共享 BLL 程序集。我正在使用 Autofac 来处理依赖关系，但没有提供一种很好的方式来管理我的配置。配置项大致相同，但值不同。有些项目使用自定义配置部分，有些则没有。

我最终得到：

  1. 创建单个 autofac 引导程序类来注册除配置文件包装器之外的所有依赖项。
  2. 使用 IConfiguration 接口创建单独的程序集（由所有项目引用）。
  3. 创建每个项目自己的 IConfiguration 实现。
  4. 通过共享引导程序在每个项目的适当位置引导依赖项。
  5. 在引导注册后单独注册项目自己的 IConfiguration 实现。

总的来说，我对 Autofac 和 DI 非常陌生，并努力在复杂性和可扩展性之间找到一个很好的平衡点。

有没有更好的方法来管理配置文件？

谢谢你。

4

2 回答 2

4

在 Autofac 中，您为此目的使用模块。相关组件组封装在一个模块中，该模块由编程 API 配置。

Autofac 的 XML 配置支持模块，所以一旦你决定在应用程序中使用一个，你可以在配置文件中注册模块（而不是它包含的所有组件）。

模块支持可以转发给内部组件的参数，例如连接字符串、URI 等。

这里的文档应该可以帮助您入门：http ://code.google.com/p/autofac/wiki/StructuringWithModules

高温高压

缺口

于 2010-01-11T11:33:53.877 回答
3

根据经验，我只将依赖项配置放在 .config 文件中，前提是它们代表了我希望能够在不重新编译应用程序的情况下进行更改。默认情况下，我没有这样的配置。

我（还）不知道 AutoFac，但是在 Castle Windsor 中，您可以混合使用 .config 和容器的编程配置，这就是我通常做的事情：我在 .config 中配置了一些依赖项，因为我希望能够无需重新编译即可更改它们，但其余部分已在代码中注册（通常按约定）。

我解决与您类似的问题的方法是制作一个包含专用容器的单独库 - 这听起来很像您的方法。这个专门的容器封装了所有常见的依赖配置。

在每个应用程序中，我都有一个更专业的容器，它派生自共享容器并覆盖它需要覆盖的任何配置。

我理解您的描述的方式似乎与您的方法相差不远，但请帮自己一个忙，并将尽可能多的配置从 XML 中移到代码中——实际上它变得更易于管理。

于 2010-01-11T10:37:26.283 回答