你为什么要在不配置的情况下使用依赖注入？

2018-06-29 10:01:34

在阅读了这个问题的精彩答案之后，我观看了Justin Etheredge的截屏视频。这一切似乎都非常好，最低限度的设置你从你的代码中获得DI。

现在我想问的是：为什么要使用不使用配置文件的DI框架？是不是使用DI基础设施的全部重点，以便您可以在构建/释放/任何代码之后改变行为（可以这么说）？

任何人都可以给我一个很好的用例来验证使用像Ninject这样的非配置DI吗？

我不认为你需要一个没有配置的DI框架。我认为你需要一个具有所需配置的DI框架。

我将以春季为例。回到过去，我们曾经把所有东西都放在XML文件中，使所有东西都可配置。

当切换到完全注释机制时，您基本上定义了应用程序包含哪些组件角色。因此，一个给定的服务可能有一个实现是“常规运行时”，其中有另一个实现属于应用程序的“Stubbed”版本。此外，在进行集成测试布线时，您可能会使用第三种实施方式。

以这种方式来看待问题时，您很快就会意识到，大多数应用程序在运行时只包含非常有限的一组组件角色 - 这些实际上会导致组件的不同版本被使用。通常，组件的给定实现始终与此角色绑定; 这实际上是该实施的原因。

所以如果你让“配置”只是指定你需要的组件角色，那么你可以在没有更多配置的情况下离开。当然，总会有例外，但是你只是处理例外。

我在krosenvold的路上，在这里，只有更少的文本：在大多数应用程序中，每个必需的“服务”只有一个实现。我们根本不写应用程序，每个对象需要10个或更多的每个服务的实现。因此，有一个简单的方法说“这是默认实现，使用此服务的所有对象中有99％会满意”。

在测试中，您通常使用特定的模型，因此不需要任何配置（因为您手动进行布线）。

这是约定配置的全部内容。大多数情况下，配置仅仅是DI框架应该知道的东西的重复转储:)

在我的应用程序中，我使用类对象作为查找实现的关键，而“关键”恰好是默认实现。如果我的DI框架在配置中找不到覆盖，它只会尝试实例化键。超过1000个“服务”，我需要四个覆盖。这将是很多无用的XML编写。

使用依赖注入单元测试变得非常简单，因为您可以在被测对象中注入模拟而不是真实对象。你不需要配置，只需在单元测试代码中创建并注入模拟。

链接地址: http://www.djcxy.com/p/82121.html