0

我(有点)对 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 方法。

就是说,我应该把这些废话撕掉,还是它正在做一些非常棒的事情而我错过了它?

4

1 回答 1

0

依赖注入背后的想法是使一个类(或另一段代码)独立于接口的特定实现。上面概述的类不知道哪个类实现IDomainFactory。具体实现通过其构造函数注入,然后由方法使用MapFromRow。域工厂返回一个ISomeDomainObject未知的实现。

这允许您补充这些接口的另一个实现,而无需更改上面显示的类。这对于单元测试非常实用。假设您有一个IDatabase定义方法的接口GetCustomerByID。很难测试使用这种方法的代码,因为它依赖于数据库中的特定客户记录。现在您可以注入一个虚拟数据库类,该类返回由不访问物理数据库的代码生成的客户。这样的虚拟类通常称为模拟对象。

请参阅Wikipedia 上的依赖注入

于 2012-11-15T19:50:28.987 回答