IoC 和依赖注入的实用性答案

【问题标题】：Utility of IoC and Dependency InjectionIoC 和依赖注入的实用性
【发布时间】：2010-03-07 01:10:51
【问题描述】：

有some cases，其中单元测试不适用于项目。

我正在研究控制反转和依赖注入实用程序，我想知道是否有充分的理由使用它而不是使单元测试更容易。

--更新

好的，我们来分析一下引用的优势之一：耦合少。您从子类型中取出耦合，并将耦合添加到需要创建要注入的对象的处理程序类型。

没有单元测试，这种耦合转移（不是耦合消除）有什么优势。

【问题讨论】：

“耦合传输”是什么意思？如果我修改我的记录器以使其接受 Stream 接口而不是特定的流实现，我将不再与具体实现耦合——我没有传输任何东西。确实，我的应用程序必须指定它们将使用哪些具体实现——这就是您所指的吗？
@Jeff Sternal 是的，我指的是。
应用程序总是与具体实现耦合，无论它们控制它们的依赖关系还是它们使用的模块控制这些依赖关系。如果我的 logger 访问文件系统，那么我的 logger 和使用它的应用程序都会耦合到文件系统实现。
是的，所以当你注入你的依赖时，你就是在转移耦合。这就是我的看法，如果我错了，我想了解。
您没有“转移”耦合，因为应用程序已经耦合到具体实现。

【解决方案1】：

IOC/DI 为您的应用程序带来了一些非常重要的特性

可插入性：使用 DI，您可以将依赖项注入代码中，而无需明确知道功能的实际工作方式。例如：您的类可能会注入一个 ILog 接口，以便它可以写入日志。由于该类使用 ILog 接口，因此可以实现 FileLog、MemoryLog 或 DatabaseLog 并将其注入到您的类中。只要实现了 ILog 接口，这些实现中的任何一个都可以正常工作
可测试性：在你的类中使用 DI，你可以注入模拟对象来测试你的类的行为，而实际上不需要具体的实现。例如：考虑一个控制器类，它需要一个存储库来执行数据操作。在这种情况下，存储库可以是控制器的 DI。如果您需要在 Controller 类上编写测试，您可以传递 DI 模拟版本的存储库，而无需使用实际的存储库类
可配置性：一些常见的 DI 框架，如 Castle Windor、Unity、Spring 等，允许执行 DI 以及创建对象的生命周期管理。这是一个非常强大的功能，允许您通过配置管理依赖项及其生命周期。例如，考虑您的应用程序需要 ICache 依赖项。通过生命周期和对象管理的配置，您将能够将缓存配置为每个应用程序或每个会话或每个请求等，而无需在代码中显式烘焙实现。

HTH

【讨论】：

【解决方案2】：

IoC 降低了coupling，这与某些studies 中的缺陷率相关。（如果这个很长的链接不起作用，那就是 Ronald Kirk Kandt 的 Software Engineering Quality Practices。）

【讨论】：

【解决方案3】：

当然，这里有几个原因：

够了吗？

【讨论】：

【解决方案4】：

来自 IoC 维基百科article：

虽然我认为上述功能列表有点含糊，但您会看到上述大部分好处，即使没有经过测试。

如果我不得不简而言之，我会说 IoC 显着改善了关注点分离，这是软件开发中的一个有价值的目标。

【讨论】：

【解决方案5】：

是的，依赖注入可以帮助您使您的类更集中、更清晰*、更容易更改，因为它更容易遵守single-responsibility principle。

它还使您可以更轻松地独立更改应用程序的各个部分。

特别是当您使用constructor injection 时，更容易告诉您的代码需要什么来完成其工作。如果WeatherUpdater 类在其构造函数中需要IWeatherRepository，那么没有人会对它使用数据库感到惊讶。

* 同样，仅构造函数注入。

【讨论】：