使用双构造函数与使用DI框架的单个构造函数的依赖注入



在单元测试的上下文中,可以创建两个控制器构造函数,默认情况下,控制器工厂将使用该构造,另一个用于单元测试。

public class ProductController : Controller 
{
  private IProductRepository repository;
  public int PageSize = 10;
  // default constructor
  public ProductController() 
  {
    this.repository = new ProductRepository();
  }
  // dedicated for unit testing
  public ProductController(IProductRepository productRepository) 
  {
    this.repository = productRepository;
  }
  public ViewResult List(int page=1) 
  {
    return View(repository.Products
       .OrderBy(p => p.ProductID)
       .Skip((page - 1) * PageSize)
       .Take(PageSize));
  }
}

可以通过这种方式实现单元测试

[TestMethod]
public void Can_Paginate() 
{
  // Arrange
  Mock<IProductRepository> mock = new Mock<IProductRepository>();
  mock.Setup(m => m.Products).Returns(new Product[] 
  {
    new Product {ProductID = 1, Name = "P1"},
    new Product {ProductID = 2, Name = "P2"},
    new Product {ProductID = 3, Name = "P3"},
    new Product {ProductID = 4, Name = "P4"},
    new Product {ProductID = 5, Name = "P5"}
  }.AsQueryable());
  ProductController controller = new ProductController(mock.Object);
  controller.PageSize = 3;
  // Act
  IEnumerable<Product> result =
  (IEnumerable<Product>)controller.List(2).Model;
  // Assert
  Product[] prodArray = result.ToArray();
  Assert.IsTrue(prodArray.Length == 2);
  Assert.AreEqual(prodArray[0].Name, "P4");
  Assert.AreEqual(prodArray[1].Name, "P5");
}

在上面我能够实现单元测试。我的问题是,如果我可以使用专用的构造函数实现DI,为什么我会选择使用DI框架(例如Unity,ninight等)?我必须在这里缺少明显的东西。

(顺便说一句,上面的代码样本主要来自亚当·弗里曼(Adam Freeman)的书ASP.NET MVC 4书,我对其进行了一些修改以适合我需要提出的问题)

在这个微不足道的例子中。从技术上讲,没有理由。

框架的重点是在全球管理依赖项及其存在的各个部分……而不仅仅是注入依赖。终身/范围,如何/何时,在哪里/为什么。您在这里拥有的仍然紧密地耦合到ProductRepository ...

在复杂的应用程序中,您目前需要这样的东西:

this.repository = new ProductRepository(
                          new ShoppingCartRepository(
                                  new Logger()),
                          new ReviewsRepository(
                                  new Logger()),
                          new Logger());

..尽管使用DI/IOC框架,您不必担心任何一个基础和所有基础的生命周期/连接逻辑。

相关内容

最新更新