如何通过依赖项注入管理配置？

我是DI / IOC的忠实粉丝。它非常适合处理/抽象出硬依赖关系，并使生活更轻松。

但是，我对此有些疑惑，我不确定该如何解决。

DI / IOC的基本思想是，当实例化对象时，其所有依赖项都将在构造函数中预先填充。

但是恕我直言，构造函数有几种类型的参数（尤其是当您的对象是不可变的时）。

依赖关系（您的对象正常工作所需的对象）
配置（有关工作所需环境的信息）
参数（完成工作的数据）

我发现IOC可以很好地处理依赖关系。但我仍在尝试找出与其他两个人打交道的最佳方法。但是，由于构造函数是要由IOC容器运行的，因此似乎需要将这些项目放入IOC容器中。

我想知道人们采用什么策略/模式，人们发现了哪些优点和缺点。

注意我知道这是一个高度主观的问题，并且根据SE指南已尝试将其设为“好”主观问题。

design-patterns configuration-management inversion-of-control

— 贸易协定
source

“配置”是指开发环境配置（例如开发或生产）吗？如果是这样，我通常将其作为传统的依赖项来处理。

— MetaFight 2014年

最好使用依赖项进行构造，但要使用默认配置，因此对象结构良好。调用其他方法来设置配置和其他参数。在ctor中执行过多操作是一件坏事。

— david.pfx 2014年

I am still trying to work out the best way to deal with the other two-将它们作为普通参数传递给您的对象？

— 罗伯特·哈维

@RobertHarvey不可变的对象？它们使调试更加容易。

— ArT 2014年

Answers:

配置（有关工作所需环境的信息）

创建一个配置类（需要挑剔的是：一个接口+一个实现），目的是提供有关环境的信息。这使配置与您的对象正常工作所需的其他对象没有任何区别（第1点）。

参数（完成工作的数据）

在面向对象的环境中，原始数据类型可以封装在对象中，因此这也指向第1点。但是您可能会发现这个SO问题很有趣，当使用DI时，它恰好处理了构造函数中原始参数的情况。容器。在给定的示例中，可以改进设计，从而完全避免了构造函数中对原始类型的需求。

— 布朗博士
source

我要做的是针对这些情况的工厂模式。

我不使用对象本身作为依赖项，而是使用Get方法创建一个工厂对象，该方法接受容器无法自动绑定的参数。

例如：

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }

— 维尔姆·普罗恰兹卡（VilémProcházka）
source