已经发布了几个关于依赖注入的具体问题，例如何时使用它以及它有什么框架，
什么是依赖注入，何时/为什么应该或不应该使用它？
当前回答
我能想到的最好的类比是手术室中的外科医生和他的助手，在那里，外科医生是主要的人，他的助手在他需要时提供各种手术组件，以便外科医生能够专注于他最擅长的一件事（手术）。如果没有助手，外科医生每次需要时都必须自己取下部件。
简而言之，DI是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见额外责任（负担）的技术。
DI使您更接近单一责任（SR）原则，就像外科医生可以专注于外科手术一样。
何时使用DI：我建议在几乎所有的生产项目（小型/大型）中使用DI，尤其是在不断变化的业务环境中：）
原因：因为您希望代码易于测试、可模拟等，以便快速测试更改并将其推向市场。此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不这样做呢。
其他回答
针对5岁儿童的依赖注入。
当你自己去把冰箱里的东西拿出来时，你可能会引起问题。你可能会让门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。你甚至可能在寻找我们甚至没有或已经过期的东西。
你应该做的是陈述一个需要，“我需要午餐时喝点东西”，然后我们会确保你坐下吃饭时有东西。
以上所有答案都很好，我的目的是用一种简单的方式解释这个概念，这样任何没有编程知识的人都可以理解这个概念
依赖注入是帮助我们以更简单的方式创建复杂系统的设计模式之一。
我们可以在日常生活中看到这种模式的广泛应用。其中一些例子是录音机、VCD、CD驱动器等。
上图是20世纪中期的便携式磁带录音机。来源
录音机的主要目的是记录或重放声音。
在设计系统时，需要一个卷轴来录制或播放声音或音乐。设计该系统有两种可能性
我们可以把卷轴放在机器里我们可以为卷轴提供一个可以放置的钩子。
如果我们使用第一个，我们需要打开机器来更换卷轴。如果我们选择第二种方式，即为卷轴设置挂钩，那么通过改变卷轴，我们可以获得播放任何音乐的额外好处。并且还将功能减少到只播放卷轴中的任何内容。
类似地，依赖注入是将依赖性外部化以仅关注组件的特定功能的过程，以便独立组件可以耦合在一起形成一个复杂的系统。
我们通过使用依赖注入获得的主要好处。
高内聚力和松耦合。外部化依赖，只关注责任。将事物作为组件，并结合起来形成具有高性能的大型系统。它有助于开发高质量的组件，因为它们是独立开发的，并且经过了适当的测试。如果一个组件出现故障，用另一个组件替换它会有帮助。
如今，这些概念构成了编程界众所周知的框架的基础。Spring Angular等是基于这一概念构建的著名软件框架
依赖注入是一种模式，用于创建其他对象依赖的对象实例，而在编译时不知道将使用哪个类来提供该功能，或者简单地将财产注入对象的方法称为依赖注入。
依赖注入示例
以前我们编写的代码是这样的
Public MyClass{
DependentClass dependentObject
/*
At somewhere in our code we need to instantiate
the object with new operator inorder to use it or perform some method.
*/
dependentObject= new DependentClass();
dependentObject.someMethod();
}
通过依赖注入，依赖注入器将为我们完成实例化
Public MyClass{
/* Dependency injector will instantiate object*/
DependentClass dependentObject
/*
At somewhere in our code we perform some method.
The process of instantiation will be handled by the dependency injector
*/
dependentObject.someMethod();
}
你也可以阅读
控制反转与依赖注入的区别
我将提出一个稍微不同的、简短而精确的依赖注入定义，侧重于主要目标，而不是技术手段（从这里开始）：
依赖注入是创建静态、无状态的服务对象图，其中每个服务由其依赖关系。
我们在应用程序中创建的对象（无论我们是否使用Java、C#或其他面向对象语言）通常分为两类：无状态、静态和全局“服务对象”（模块），以及有状态、动态和本地“数据对象”。
模块图（服务对象图）通常在应用程序启动时创建。这可以使用容器（如Spring）完成，但也可以通过向对象构造函数传递参数来手动完成。这两种方法都有其优点和缺点，但在应用程序中使用DI肯定不需要框架。
一个要求是服务必须通过其依赖性进行参数化。这意味着什么完全取决于给定系统中采用的语言和方法。通常，这采用构造函数参数的形式，但使用setter也是一种选择。这也意味着（在调用服务方法时）对服务的用户隐藏服务的依赖关系。
何时使用？我会说，每当应用程序足够大时，将逻辑封装到单独的模块中，在模块之间使用依赖关系图，可以提高代码的可读性和可探索性。
依赖注入是一种实践，它使解耦的组件与它们的一些依赖不可知，这遵循SOLID准则
依赖反转原则：一个人应该“依赖于抽象，而不是结核。
依赖注入的更好实现是Composition Root设计模式，因为它允许组件与依赖注入容器分离。
我再次推荐这篇关于作文根的伟大文章http://blog.ploeh.dk/2011/07/28/CompositionRoot/作者：Mark Seemann
本文的要点如下：
合成根是应用程序中的（最好）唯一位置其中模块被组合在一起。
...
只有应用程序应该具有合成根。图书馆和框架不应该。
...
DI容器只能从合成根引用。所有其他模块都不应引用容器。
Di Ninja（依赖注入框架）的文档是一个很好的例子，可以演示组合根和依赖注入的原理是如何工作的。https://github.com/di-ninja/di-ninja正如我所知，是javascript中唯一实现Composition Root设计模式的DiC。
到目前为止，我找到的最好的定义是詹姆斯·肖尔的定义：
“依赖注入”是25美元5美分概念的术语。[...]依赖注入意味着对象的实例变量。[...].
马丁·福勒的一篇文章可能也很有用。
依赖注入基本上是提供对象所需的对象（其依赖项），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许对依赖项进行嘲笑或清除。
依赖关系可以通过多种方式注入到对象中（例如构造函数注入或setter注入）。甚至可以使用专门的依赖注入框架（例如Spring）来实现这一点，但它们肯定不是必需的。您不需要这些框架进行依赖注入。显式实例化和传递对象（依赖项）与框架注入一样好。
