适用于小型.NET项目的IoC/DI

Question

对于大型项目而言,IoC/DI框架提供的关注点的分离不能过高估计,但在小型项目中是否存在这种技术的位置？

您可以分享一些您在编写另一个小型/平均项目时发现有用的IoC/DI框架的实际用途.

为了定义:

一个"小项目"包含100-1000行代码(balpark,只是为了给出一个想法),代码需要1-3天,生成的应用程序在被丢弃或退出之前的生命周期在1周内 - 首次发布后5年(这是很难在小型/平均/大型项目之间划一条线).

谢谢.

Answer 1

对于一个小项目,我很想继续使用依赖注入,但不使用框架.只需在入口点处制作所有依赖项.您仍然可以获得可测试性的所有好处,并且您可以在以后继续使用完全成熟的容器 - 但您不必担心设置容器,直到它实际上有用.

我已经在几个小项目中使用了这种方法,并且它运行得非常好.当然,这取决于你的依赖是多么复杂 - 他们是否需要工厂,有不同的范围等 - 但如果它只是"我有这三件事都依赖于认证服务"那么这非常简单.

Answer 2

但在一个小项目中是否有这样的技术的地方？

即使在小型项目中,您也应该使用IoC模式来削弱层之间的耦合并使其可单元测试.始终使用抽象.您是否使用DI框架并不重要.在小项目中,您可以简单地手动执行依赖项的管道,不需要对象容器来执行依赖项注入,但是当您再次考虑它时,为什么不呢？

Answer 3

取决于您认为在实施中重要的内容.如果可测试性很重要,并且如果您倾向于遵循单一责任原则(在小型或大型项目中),那么您通常会得到比您可能更多的类.这可能会导致调用

var svc = new ShippingService(new ProductLocator(), 
                              new PricingService(), 
                              new InventoryService(), 
                              new TrackingRepository(new ConfigProvider()), 
                              new Logger(new EmailLogger(new ConfigProvider())));

如果你可以忍受这个,我个人也会,在一个扔掉的应用程序,然后无论如何你真的不需要一个DI容器.去做任何让你快乐的事情.干杯.

编辑:

多年来,我发现TinyIoC是小型项目的良好折衷方案.