通过构造函数或属性设置器进行依赖注入？

我正在重构一个类，并为其添加新的依赖关系。该类当前正在构造函数中使用其现有的依赖项。因此，为了保持一致性，我将参数添加到构造函数中。
当然，有一些子类，甚至还有更多用于单元测试的子类，所以现在我正在玩改变所有构造函数以匹配的游戏，并且这需要很长时间。
它使我认为，将属性与setter一起使用是获取依赖项的更好方法。我不认为注入的依赖关系应该是构造类实例的接口的一部分。您添加了一个依赖项，现在所有用户（子类以及直接实例化您的任何人）突然都知道了。感觉就像封装的破坏。

这似乎不是此处现有代码的模式，因此我希望了解什么是一般共识，即构造函数与属性的优缺点。使用属性设置器更好吗？

这要看情况 ：-）。

如果类在没有依赖项的情况下无法完成其工作，则将其添加到构造函数中。该类需要新的依赖关系，因此您希望所做的更改使事情中断。同样，创建未完全初始化的类（“两步构造”）也是一种反模式（IMHO）。

如果该类可以在没有依赖项的情况下工作，则可以使用setter。

类的用户应该知道给定类的依赖关系。如果我有一个类，例如，一个连接到数据库的类，并且没有提供注入持久层依赖的方法，那么用户将永远不会知道必须要有一个与数据库的连接。但是，如果我更改了构造函数，则会让用户知道持久层存在依赖性。

另外，为避免自己不得不改变对旧构造函数的每次使用，只需将构造函数链接作为新旧构造函数之间的临时桥梁即可。

public class ClassExample
{
    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo)
        : this (dependnecyOne, dependencyTwo, new DependnecyThreeConcreteImpl())
    { }

    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo, IDependencyThree dependencyThree)
    {
        // Set the properties here.
    }
}

依赖注入的要点之一就是揭示类具有什么依赖。如果类具有过多的依赖关系，那么可能是时候进行一些重构了：类的每个方法都使用所有依赖关系吗？如果不是这样，那么这是查看可以在哪里拆分类的一个很好的起点。

当然，使用构造函数意味着您可以一次验证所有内容。如果将事物分配给只读字段，那么从构造开始就可以保证对象的依赖性。

添加新的依赖关系确实很痛苦，但是至少以这种方式，编译器一直抱怨直到正确为止。我认为这是一件好事。

如果您有大量的可选依赖项（已经是一种气味），那么setter注入可能是可行的方法。构造函数注入可以更好地揭示您的依赖关系。

通常首选的方法是尽可能使用构造函数注入。

构造函数注入准确地说明了对象正常运行所需的依赖项-没有什么比新建对象和在调用该对象的方法时使它崩溃（因为未设置某些依赖项）更令人讨厌的了。构造函数返回的对象应处于工作状态。

尝试只有一个构造函数，这样可以简化设计并避免歧义（如果不是对于人类，对于DI容器）。

当Mark Seemann 在他的书“ .NET中的依赖项注入”中有了本地默认值时，就可以使用属性注入：依赖项是可选的，因为您可以提供良好的工作实现，但希望允许调用方指定其他不同的实现。需要。

（下面是以前的答案）

我认为，如果强制性注入，则构造函数注入会更好。如果这增加了太多的构造函数，请考虑使用工厂而不是构造函数。

如果注射是可选的，或者您想在中途更改它，则setter注射是不错的选择。我通常不喜欢二传手，但这是一个品味问题。

这很大程度上取决于个人喜好。就我个人而言，我倾向于使用setter注入，因为我相信它可以在运行时替代实现的方式为您提供更大的灵活性。而且，在我看来，带有很多参数的构造函数并不干净，并且在构造函数中提供的参数应限于非可选参数。

只要类接口（API）清楚执行任务所需的内容，就可以了。

我个人更喜欢“ 提取并重写 ”“模式”，而不是在构造函数中注入依赖项，这在很大程度上是出于问题中概述的原因。您可以将属性设置为virtual，然后在派生的可测试类中覆盖实现。

我更喜欢构造函数注入，因为它有助于“增强”类的依赖关系要求。如果在目录中，则消费者必须设置对象才能编译应用程序。如果您使用setter注入，他们可能直到运行时才知道它们有问题-并且取决于对象，运行时可能会延迟。

当注入的对象本身可能需要大量工作（例如初始化）时，我仍会不时使用setter注入。

我进行构造函数注入，因为这似乎是最合逻辑的。就像说我的课需要这些依赖关系来完成其工作一样。如果它是可选的依赖项，那么属性似乎是合理的。

我还使用属性注入来设置容器没有引用的内容，例如使用容器创建的演示者上的ASP.NET视图。

我认为它不会破坏封装。内部工作应保持内部状态，而依赖项应处理不同的问题。

一种可能值得考虑的选择是从简单的单个依赖关系中构成复杂的多重依赖关系。也就是说，为复合依赖项定义额外的类。这使事情变得更容易WRT构造函数注入-每个调用的参数更少-同时仍保持必须供应所有依赖关系来实例化事物。

当然，如果存在某种逻辑依赖关系组，这是最有意义的，因此该复合物不仅仅是一个任意集合，并且对于单个复合依赖物有多个依赖物，这是最有意义的-但是参数块“模式”具有已经存在了很长时间，而我见过的大多数对象都是相当武断的。

不过，就我个人而言，我更喜欢使用方法/属性设置器来指定依赖项，选项等。调用名称有助于描述正在发生的事情。不过，最好提供示例“如何设置”片段，并确保相关类进行足够的错误检查。您可能要对安装使用有限状态模型。

最近，我遇到了一个类中有多个依赖项的情况，但是每个实现中只有一个依赖项必须更改。由于数据访问和错误日​​志记录的依赖关系可能仅出于测试目的而更改，因此我为这些依赖关系添加了可选参数，并在构造函数代码中提供了这些依赖关系的默认实现。这样，除非类的使用者将其覆盖，否则该类将保持其默认行为。

使用可选参数只能在支持它们的框架中完成，例如.NET 4（适用于C＃和VB.NET，尽管V​​B.NET始终具有它们）。当然，您可以通过简单地使用可以由类的使用者重新分配的属性来实现类似的功能，但是您不能通过将私有接口对象分配给构造函数的参数来获得不变性的优势。

综上所述，如果要引入一个必须由每个使用者提供的新依赖关系，则将必须重构构造函数以及使用者类的所有代码。我上面的建议实际上仅在您能够为所有当前代码提供默认实现的情况下适用，而在必要时仍提供覆盖默认实现的功能。

这是一个旧帖子，但是如果将来需要它，则可能有用：

https://github.com/omegamit6zeichen/prinject

我有一个类似的想法，并提出了这个框架。它可能还远未完成，但它是一个专注于属性注入的框架的想法

这取决于您要如何实现。我更喜欢在不需要经常更改实现值的地方进行构造函数注入。例如：如果Oracle服务器采用了Compagy策略，那么我将为通过构造函数注入实现连接的bean配置datsource值。否则，如果我的应用是产品，并且有机会可以连接到客户的任何数据库，我将通过setter注入来实现这种数据库配置和多品牌实施。我只是举了一个例子，但是有更好的方法来实现上述场景。

如果在构造函数中检查了参数，构造函数注入确实显式揭示了依赖关系，从而使代码更易读，并且不太可能发生未处理的运行时错误，但这确实取决于个人看法，并且使用DI越多，您将得到的收益就越多。倾向于根据项目来回摇摆。我个人在代码气味方面有问题，例如带有一长串参数的构造函数，并且我觉得对象的使用者应该知道依赖关系才能使用该对象，因此这为使用属性注入提供了理由。我不喜欢属性注入的隐式本质，但是我发现它更加优雅，从而使代码看起来更简洁。但另一方面，构造函数注入确实提供了更高的封装度，

根据您的特定情况，按构造器或按属性选择注入。而且不要觉得仅仅因为看起来有必要而必须使用DI，这样就可以防止不良的设计和代码气味。有时，如果付出的努力和复杂性超过了收益，那么使用这种模式就不值得付出努力。把事情简单化。