为什么在没有配置的情况下需要依赖注入？

在阅读了这个问题的好答案后,我观看了Justin Etheredge的截屏视频.这一切看起来都非常好,只需最少的设置就可以从代码中获得DI.

现在我的问题是:为什么你要使用不使用配置文件的DI框架？这不是使用DI基础设施的重点,以便您可以在构建/发布/无论代码之后改变行为("策略",可以这么说)吗？

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

我不认为你想要一个没有配置的DI框架.我想你想配置的DI框架需要.

我以春天为例.回到过去的"旧时代",我们过去常常将所有内容都放在XML文件中,以使所有内容都可配置.

切换到完全注释的方案时,您基本上定义了应用程序包含的组件角色.因此,给定服务可以例如具有一个用于"常规运行时"的实现,其中存在属于应用程序的"Stubbed"版本的另一实现.此外,在进行集成测试时,您可能正在使用第三种实现方式.

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

因此,如果您让"配置"只是指定您需要的组件角色,那么您可以在没有更多配置的情况下离开.当然,总会有例外,但是你只需处理异常.

我正在使用krosenvold的路径,这里只使用较少的文本:在大多数应用程序中,每个所需的"服务"只有一个实现.我们根本不编写应用程序,其中每个对象需要每个服务的10个或更多实现.因此,有一个简单的方法说"这是默认实现,使用此服务的所有对象的99%将满意"是有意义的.

在测试中,您通常使用特定的模型,因此不需要任何配置(因为您手动进行连接).

这就是配置约定的全部内容.大多数情况下,配置只是一个转储重复的东西,DI框架应该知道:)

在我的应用程序中,我使用类对象作为查找实现的键,而"键"恰好是默认实现.如果我的DI框架在配置中找不到覆盖,它将尝试实例化密钥.有超过1000个"服务",我需要四个覆盖.那将是很多无用的XML写.