我理解依赖注入（DI）是什么（我认为！）。它基本上是对象可能具有的依赖性的满足。我尝试考虑使用DI作为面向服务时编写的代码，并将代码定义为使用其他服务。
然而，我现在想知道在使用IoC时我们正在反转控制权是什么。这是一个相当含糊的术语，它可能意味着一些事情。
但是，我认为由IoC框架处理创建对象（因此使用DI来满足依赖性）的责任。
应用程序仍然有责任询问它使用的对象（即 - 服务），区别在于它不知道（或关心）如何创建它。那么，为什么服务定位器被认为是一种反模式，如果它所做的只是要求服务呢？
我说得对吗？或者它是否意味着别的东西。另外，我是否正确分离了DI和IoC的职责？如果我有一个IoC框架，没有DI框架就无法运行。或者DI只是IoC框架的一个特性吗？
答案 0 :(得分：9)
依赖注入通常意味着将依赖对象作为参数传递给方法，而不是让方法创建依赖对象。在实践中它意味着该方法不直接依赖于特定的实现;任何满足要求的实现都可以作为参数传递。
控制反转简单地认识到依赖关系是相反的。通过直接创建，实现或调用它而不是A取决于B，A接收B作为参数，并且不再以任何方式对B负责。
将参数类型实现为接口简化了流程并对其进行了概括，但并不是绝对必要的。
答案 1 :(得分：3)
控制反转是一种普遍的模式。依赖注入是该模式的一种用法。有关详细信息，请this article by Martin Fowler，特别是标题为“控制反转”的部分。
很多人现在都避免使用DI的“反转控制”一词，因为这种反转与人们在依赖注入变得普遍之前做事情的方式相比较。如果你现在已经习惯了依赖注入，或者是一个有幸从一开始就这么想的人，那么试图找出被倒置的东西只会让人感到困惑。
答案 2 :(得分：0)
控制反转基本上意味着应用程序代码并不关心它所需部件的来源。
您可以通过各种依赖注入来实现IoC。
与Java世界中的相反，包装器可能通过jndi按名称请求资源。在这种情况下，代码要求它需要，而不是提供它。
你说“应用程序的责任仍然是要求它使用的对象（即服务），区别在于它不知道（或关心）如何创建它。”
我不认为这是真的;组件不要求其他组件。依赖关系是从更高级别注入的，这是一种不同的语义。这就是IoC。