design-patterns - 依赖注入(inject)是一种模式吗？是吗？

Question

我与我的一位同事就依赖注入(inject)进行了激烈的辩论，并意识到我并不完全了解该主题的所有事实。

所以，拿这个代码(只是让你知道，我们使用的是温莎城堡)

IPlayerService service = Container.Resolve<IPlayerService>();

上面的代码显然是一个使用 IoC 的 DI 示例。

但是，请参阅下面的代码( 更新:假设我通过构造函数传递所有外部依赖项 ):

var playerClient = new PlayerClient();
var playerSkinClient = new PlayerSkinClient();
IPlayerService service = new PlayerService(playerClient, playerSkinClient);

我的论点是上面的代码是 DI 模式的一个例子，DI 可以在没有 IoC 的情况下存在。

现在，我的同事并没有完全不同意我的观点，但他说上面的代码不是任何涉及 DI 的模式的示例。

那么，DI 是否可以仅用作一种模式而无需任何额外的框架？

如果是这样，上面的代码是它的一个例子吗？

最后，是什么定义了 DI 模式(如果存在)，没有容器的概念。

更新

今晚晚些时候我将更彻底地浏览答案和评论，但只是想感谢大家迄今为止深思熟虑的答案和评论!

Answer 1

根据该主题专家 Martin Fowler 的说法，依赖注入(inject)是被称为控制反转 (full article) 的抽象概念的具体实现的另一个名称。

从根本上讲，所有 DI 意味着:一个类依赖于正确工作的对象被初始化并从外部传递给它，而不是类本身负责获取/初始化这些对象。如何实现这一点的细节超出了该模式的范围。

IoC 是一回事，但正如 Martin Fowler 所说，说“控制反转”是描述正在发生的事情的一种非常迟钝的方式。

我个人认为“依赖注入(inject)”并没有好得多。我将其描述为“正确使用构造函数”。

非 IoC/非 DI 示例:

class Foo
{
    void DoSomething()
    {
        DbConnection myConnection = new DbConnection(ConfigurationSettings...);
        myConnection.ExecuteCommand();
    }
}

使用 IoC/DI 也是一样:

class Foo
{
    private DbConnection myConnection;

    public Foo(DbConnection conn)
    {
        myConnection = conn;
    }

    void DoSomething()
    {
        myConnection.ExecuteCommand();
    }
}

我恭敬地不同意那些认为它不是真正的 IoC/DI 的人，除非你有一个显式的 binder/assembler/what-have-you 将注入(inject)的类型与具体的实现连接起来，因为接收依赖项的类不知道不同之处。无论您是在外部类中还是在外部配置文件中安排依赖关系，都是一个实现细节。