我对DI(有点)陌生，正在努力理解它是如何/为什么在我维护的代码库中使用的。我发现了一系列类，它们将存储过程调用中的数据映射到域对象。例如：
Public Sub New(domainFactory As IDomainFactory)
_domainFactory = domainFactory
End Sub
Protected Overrides Function MapFromRow(row As DataRow) As ISomeDomainObject
Dim domainObject = _domainFactory.CreateSomeDomainObject()
' Populate the object
domainObject.ID = CType(row("id"), Integer)
domainObject.StartDate = CType(row("date"), Date)
domainObject.Active = CType(row("enabled"), Boolean)
Return domainObject
End Function
IDomainFactory注入了Spring.Net。它的实现只是有一系列方法来返回各种域对象的新实例。例如：
Public Function CreateSomeDomainObject() As ISomeDomainObject
Return New SomeDomainObject()
End Function
上面所有的代码让我觉得比无用的还要糟糕。这很难遵循，也没有任何价值。此外，据我所知，这是对DI的滥用，因为它并不是真正用于局部变量的。此外，我们不需要域对象的多个实现，我们不做任何单元测试，如果我们做了，我们仍然不会模拟域对象。从上面的代码中可以看出，对域对象的任何更改都将是对SP的更改的结果，这意味着无论如何都必须编辑MapFromRow方法。
也就是说，我应该把这些废话扯出来，还是它在做一些令人惊叹的事情，而我却错过了它？
依赖注入背后的思想是使一个类(或另一段代码)独立于接口的特定实现。上面列出的类不知道是哪个类实现了IDomainFactory。通过其构造函数注入了一个具体的实现，随后由方法MapFromRow使用。域工厂返回ISomeDomainObject的一个实现，该实现也是未知的。
这允许您补充这些接口的另一个实现，而不必更改上面显示的类。这对于单元测试来说非常实用。假设您有一个定义方法GetCustomerByID的接口IDatabase。很难测试使用这种方法的代码，因为它取决于数据库中的特定客户记录。现在，您可以注入一个伪数据库类，该类返回由不访问物理数据库的代码生成的客户。这样的伪类通常被称为mock对象。
请参阅维基百科上的依赖项注入。