害怕使用依赖注入框架

Question

我一直在阅读依赖注入框架。我真的爱上了分离关注点并让对象完成其核心工作的想法 - 这无疑是一个优秀且长期存在的设计原则！

然而，我对 DI 框架了解得越多，我就越担心： 1）他们“自动”解决依赖关系的方式 2）关于配置文件中引入的极端复杂性

就第二点而言，我看到我的客户花费数百万美元来培训人们使用产品，其中重要的部分是如何“不”接触配置文件。管理员现在害怕这些配置文件。

尽管如此，我看到了另一种称为服务定位器的模式，我可以在应用程序开始时很好地组装我想要的所有“全局”服务（可能是应用程序主机或应用程序上下文或其他）。使该服务定位器在全球范围内可用，瞧！

然而，我发现当我需要基于某种标准（谁知道？）的不止一种类型的“全局”服务时，使用服务定位器方法的灵活性会降低！

所以，在这里我比以前更困惑该往哪个方向走。虽然我非常喜欢它的设计原理，但现有框架的复杂性让我望而却步！

我的担忧是真实的吗？还有其他人有同样的感觉吗？如果是这样，对于如此巨大的压倒性“框架”，有什么好的替代方案吗？

Answer 1

我个人非常喜欢使用 Autofac。容器配置是通过代码完成的，同时消除了冗长的 XML 并启用了重构支持。

不过，最好的功能之一是模块。它们是容器配置的单元，允许您管理组成应用程序的许多不同组件的复杂性。

我目前正在开发一个非常大的项目，体验与小型项目时大致相同，这意味着这种方法的扩展性非常好。

支持 DI 的类的一个主要原则是它们不引用基础结构代码。这是服务定位器模式的对立面。服务定位器的主要缺点是，除了增加引用容器的类的复杂性之外，还无法更改解析的依赖项的版本。

对于不引用容器的“纯”类，任何给定依赖项的解析版本都位于正在注入的类的外部。

Answer 2

正如内特提到的，“魔法”是可选的；如果需要，您可以手动配置所有内容。

我最初（或永远！）会避免使用配置文件，并在代码中配置容器。这往往更容易阅读和维护。大多数时候您不需要即时更改配置。客户无法触及配置文件，因为它们不存在。

服务定位器也有缺点；其一，他们倾向于将您的类与定位器类/框架结合起来。一个好的 DI 框架会让你使用普通的旧对象；您的项目中可能只有一个实际使用 DI/IoC 框架的类。

StructureMap 和 Unity 都非常简单；尝试一下。从小处开始。

这是一个非常简单的 Unity 示例（包括内联配置）：

using Microsoft.Practices.Unity;

static void Main()
{
    using (IUnityContainer container = new UnityContainer())
    {
        container.RegisterType<IRobot, MrRoboto>();

        Console.WriteLine("Asking Unity container to give us a Model...");

        Model model = container.Resolve<Model>();
        model.MoveRobot();
    }
}

// class Model

public Model(IRobot robot)
{
    // Unity will hand the constructor an instance of MrRoboto!
}

Answer 3

如果您确实考虑采用依赖注入路线，我强烈建议快速阅读 Martin Fowler 的优秀依赖注入文章：

http://martinfowler.com/articles/injection.html

我现在正在开发一个包含大量配置文件的 Java 项目。我们预先选择单例模式来表示我们的配置（有点类似于全局解决方案）。以下是让我发疯的事情，让我希望我们有一个依赖注入模式：

1. 使用全球化模式进行单元测试很糟糕。依赖注入模式很容易进行单元测试，尤其是模拟对象测试。在单例类型的情况下，您现在拥有所有这些单元测试，但仍然需要可用的全局状态才能运行。通过依赖注入，您可以创建传递到测试中的特定于测试的模拟配置对象。我无法夸大这使得单元测试变得多么容易。另一篇题为“Endo-Testing：使用模拟对象进行单元测试”的优秀论文：http://connextra.com/ aboutUs/mockobjects.pdf

2. 使用全球化的方法在较小的系统中效果更好，但随着线程数量的增长，它们都开始争夺配置资源。您可能会遇到同步问题，并且您的配置访问甚至可能开始成为瓶颈。这对我们来说还不是一个大问题，但它开始让我们所有人烦恼。

3. 一旦你沿着非依赖注入路线走了一小段路，就没有真正的回头路了。从依赖注入到某种全球化模式很烦人，但在逐步的基础上是可行的。尝试从全球化模式回到依赖注入是一场噩梦。我一直想在我们的项目中这样做，但我做不到。这将需要整个开发周期。

不管怎样，希望这篇文章和经验能帮助你做出决定。我在你考虑的道路上还有很长的路要走，我有点希望我们能采取依赖注入路线:-D

Answer 4

这些都不是 DI“必需的”——它们是某些 DI 框架提供的选项。就我个人而言，我也不喜欢“自动”注入 - 我可以看到它适用于非常小的项目，但会在较大的项目上引起问题。对于第 2 点 - 我不确定我是否明白这一点 - 我主要使用 Spring。 Spring 提供 XML 和 Java 配置选项。它提供嵌套配置。如果配置的一部分您不希望任何人更改，而另一部分您却需要更改（将它们分成单独的配置文件），或者将一个 XML 和另一个 Java 设为“可更改”。 Spring 还支持使用属性文件中的值，这就是我希望管理员更改的所有内容 - 管理员不是程序员 - 他们不应该“重新连接”您的应用程序 - 只是提供适当的选项。

Answer 5

根据您使用的语言，有些 DI 框架并不那么可怕，尽管您会有一些配置文件，但它们不应该是可怕的，而是有用的。

例如，我有一个用于开发的配置文件，一个用于测试，一个用于生产。

因此，根据我使用的数据库连接可以更改，我可以换出数据库层进行测试，并使用模拟测试。

系统管理员应该控制生产配置文件，因为理想情况下，开发人员不应将任何内容推送到生产中。

Spring 对 DI 有一个很好的设置，尽管它并不轻量。

我发现 Unity 框架学习起来并不简单，但是一旦您使用它，添加新的注入类就变得非常容易。

因此，一开始，任何新的东西都可能会让人害怕，但当您熟悉这个概念时，您就会看到优点，例如我解释的三个配置文件。

Answer 6

我的情况可能与您的情况不同，因为我们已经拥有一个专为非常灵活的配置而设计的系统，因此向该配置添加依赖项注入几乎是微不足道的，但在我看来，使用服务定位器模式不会为您节省太多配置，因为您必须这样做仍然指定如何定位服务。能够灵活地注入模拟对象进行测试对于使用依赖注入来说几乎是无价的好处，所以我想说配置开销可能只是您需要接受才能获得好处的业务成本。