在Unity中解析类型时传递构造函数参数：最佳做法

Question

当使用依赖注入来提供在构造函数中使用的参数时，有时需要这样做。这是在Unity（和其他依赖注入容器）中支持的东西，所以当它试图创建类型的实例时，它可以在构造函数中提供参数作为参数。

我的问题是：这种方法是否可取？

内的接口是不可能指定哪些参数的实现类必须有。通过给Unity指定参数，假定实现类具有这些参数，并且将对未来的实现类进行隐式约束。这些约束无法通过接口传递。

那么，这是如何接口本身指定（在.NET）的缺陷，例如。应该可以指定构造函数签名吗？或者由于其他的需要，这个功能（能够提供构造参数）包含在Unity中吗？

唯一真正可行的方法（对我来说）似乎是使用一个工厂来创建实现类，并做了工厂依赖注入。

我很感激我的问题在这里可能不是很清楚，所以我会问它略有不同：什么是应该做在具有需要参数的构造函数的类的依赖注入的最佳方式？

（我不相信这个问题是主观的，因为有可能应该是这种类型的依赖注入的单一设计模式。）

编辑：

我要补充一点，我的主要问题是我可以创建一个新的实现类，它具有额外的构造函数参数（其中构造函数参数不是可以通过统一创建的东西）。

Answer 1

IoC容器（比如统一）的职责是与接口的具体实现连接。这意味着你的容器必须知道接口以及如何创建实现接口的对象。使用构造函数注入是完全合法的，也是推荐的方式。当您的应用程序通过Resolve（）方法请求一个接口时，Unity将创建具体的实现。 Unity容器本身是创建对象的工厂，因为您不想自己实现这些工厂，所以使用Unity。

Answer 2

我不确定你在哪里得到构造函数注入不适合DI的想法。我认为真实情况与此相反：构造函数注入是用于实现依赖注入的最常见模式之一 - 我甚至可以说它是最常见的模式，而该视图当然大多数控制反转容器（DI容器）使用构造器注入作为他们的首选机制这一事实支持了这一点。

StructureMap例如有一个核心，为构造函数注入它会选择最参数用于解决依赖构造函数的构造非常具体的支持。

你在说什么使用构造函数注入模式是“我通过指定它们作为传入构造函数的参数来移除我的类中的硬编码依赖项 - 我的类无法在没有这些依赖项的情况下实例化”。当然，这个声明的前半部分是DI的本质，但下半场更强调这一点。

依赖关系是应该能够轻松更改的实现细节，提供了一个灵活的，松散耦合的解决方案。他们是关于如何，而不是什么。接口指定了什么。所以我会说，你在接口中指定依赖关系的建议实际上违背了依赖注入的概念。

至于你关于工厂的陈述 - 这正是IOC容器的意义 - 伟大的大工厂负责解决方案的依赖树，所以你不需要关心。

编辑

我想，也许你是问要提供非依赖构造函数的参数的情况下，如为引用实体的ID，或初始状态枚举？

我个人没有看到IOC容器允许这个问题。它仍然是你的阶级的初始状态，因此需要明确表达该状态的创建规则。这可能意味着您有时需要更多参考您所喜欢的IOC容器，但放弃注射器注入的其他好处并非可怕的情况。

Answer 3

这里的问题是Unity中InjectionConstructor的定义，比如说Castle.Windsor中的一个。

在Unity中，如果你需要注入一个特定的参数，比如说一个AppSetting，你也被迫提供所有其他参数，从而修复构造函数的签名。但是，在Castle.Windsor中，它使用您提供的参数，然后使用解析机制以正常方式查找其他参数。

这将有可能通过编写做了一个“最适合”的方式来使用它的构造函数，而不是默认的贪婪/提供一切这是默认的自定义生成器战略，引入统一这一点。