依赖注入是一种模式吗，这是吗？
我和我的一位同事就依赖注入问题进行了激烈的辩论，我意识到我并不完全了解这个问题的所有事实。
所以，拿着这段代码(你知道，我们用的是温莎城堡)
IPlayerService service = Container.Resolve<IPlayerService>();上面的代码显然是使用IoC的DI示例。
但是，请参见下面的代码(UPDATE:假设我通过构造函数传递所有外部依赖项)：
var playerClient = new PlayerClient();
var playerSkinClient = new PlayerSkinClient();
IPlayerService service = new PlayerService(playerClient, playerSkinClient);我的论点是，上面的代码是DI模式的一个例子，DI可以在没有IoC的情况下存在。
现在，我的同事并没有完全不同意我的观点，但是他说，上面的代码不是任何涉及DI的模式的例子。
- 那么，DI是否可以作为一种模式使用而不需要任何额外的框架工作呢？
- 如果是这样的话，上面的代码是其中的一个例子吗？
- 最后，什么定义了DI模式，如果它存在的话，没有容器的概念。
更新
今晚晚些时候，我将更深入地研究答案和评论，但我只想感谢大家给出的答案和评论。
回答 8
Stack Overflow用户
发布于 2010-06-30 00:47:49
在Java世界中，依赖注入通常涉及框架、容器等等。但不需要那么多机器。
依赖注入的本质是一个类能够被分配它所依赖的对象，而不是让它们在实现中硬编码。如果您可以从类外部“注入”那些“依赖项”，那么就有依赖项注入。一个框架可能是一个很好的方法，但它并不是必需的。
在Python世界中，不存在依赖注入框架的文化，因此那里的许多程序员都想知道所有的小题大做是为了什么。对他们来说，DI“只是”能够将对象或类传递给构造函数。
要回答你的具体问题：
- 是的，DI可以在没有框架的情况下完成。
- 是的，上面的代码就是一个例子: PlayerService不知道PlayerClient或PlayerSkinClient从何而来。他们已经被注射进课堂了。请注意，这里的其他人已经回答了这个“否”。
- 请参见上面的。
Stack Overflow用户
发布于 2010-06-30 00:42:07
马丁·福勒( Martin )是这个问题的专家，他认为，依赖注入是抽象概念的另一个名称，这个抽象概念被称为“控制反转”(整篇文章)。
从根本上讲，DI的意思是:类依赖于正确工作的对象被初始化并传递到外部，而不是类本身负责获取/初始化这些对象。如何完成这一任务的细节超出了模式的范围。
IoC也是一回事，但正如Martin所说，“控制反转”是描述正在发生的事情的一种非常迟钝的方式。
但就我个人而言，我并不认为“依赖注入”更好。我将其描述为“正确使用构造函数”。
非IoC/non的示例：
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的人，除非您有一个显式的绑定器/汇编程序/什么的-您将注入的类型与具体的实现连接起来，因为接收依赖项的类不知道它们之间的区别。无论是在外部类中安排依赖项，还是在外部配置文件中安排依赖项，都是实现细节。
Stack Overflow用户
发布于 2010-06-30 01:24:09
那么，DI是否可以作为一种模式使用而不需要任何额外的框架工作呢？
是的，完全正确。
如果是这样的话，上面的代码是其中的一个例子吗？
是的，完全正确。
最后，什么定义了DI模式，如果它存在的话，没有容器的概念。
对象被赋予它所依赖的一切；它的依赖性被注入其中。
https://stackoverflow.com/questions/3145764
复制相似问题
腾讯云开发者
