何时使用依赖注入
最近几天我有一种特定的感觉，认为依赖注入应该被称为“我无法下定决心” - 模式。 我知道这可能听起来很愚蠢，但实际上这是关于为什么我应该使用依赖注入（DI）的原因。 通常情况下，我应该使用DI来实现更高级别的松耦合，并且我会得到这一部分。 但是真的......一旦我的选择落在MS SQL或MySQL上，我多久才能更换一次数据库。很少有正确的方法吗？
有没有人有一些非常有说服力的理由，为什么DI要走？
两个单词，单元测试。
DI最引人注目的原因之一是允许更简单的单元测试，而无需打开数据库并担心设置“测试”数据。
DI对于解耦您的系统非常有用。 如果你使用它的目的是为了将数据库实现与应用程序的其余部分分离开来，那么你的应用程序非常简单，或者你需要对问题域进行更多的分析，并发现问题域中的组件是最有可能发生变化以及系统中具有大量耦合的组件。
当您针对代码重用，多功能性和对问题域更改的稳健性时，DI是最有用的。
它与您项目的相关程度取决于代码的预期寿命。 取决于您正在从一个项目到下一个项目进行零重用的工作类型，因为您正在编写的大部分代码实际上可能是完全可以接受的。
使用DI的一个例子是创建一个应用程序，可以使用DI为客户端部署多个客户端，为客户端注入定制，也可以将其描述为GOF策略模式。 使用DI框架可以促进许多GOF模式。
DI与企业应用程序开发更相关，在这种开发中，您有大量代码，复杂的业务需求以及系统将维护多年或数十年的期望（或希望）。
即使您在开发阶段不改变程序的结构，您也会发现需要从程序的不同部分访问多个子系统。 通过DI，每个班级都需要提供服务，而且您无需手动提供所有接线。
这确实帮助我专注于软件设计中的事物交互，而不是“谁需要随身携带，因为其他人需要它”。
此外，它也只是节省了大量编写样板代码的工作。 我需要单身吗？ 我只是将一个类配置为一个类。 我可以用这样的“单身”来测试吗？ 是的，我仍然可以（因为我只是配置它只存在一次，但测试可以实例化一个替代实现）。
但是，在我使用DI之前，我并没有真正了解它的价值，但是尝试它让我大开眼界：我的设计比以前更加面向对象。 顺便说一下，在目前的应用程序中，我不会进行单元测试（坏的，坏的我），但我仍然无法忍受DI。 移动事物并保持课堂小而简单是非常容易的。
链接地址: http://www.djcxy.com/p/82055.html