c# - 新 MVC3 项目中的 InversionOfControl

Question

我正在使用 C#、MVC3、Entity Framework 4 构建一个电子商务网站，这是我第一次接触 MVC3 和 Entity Framework，因此我想确保一个健全的架构。特别是，我质疑我对接口(interface)和依赖倒置的使用，因为它们与服务和存储库层有关。为了简洁明了，我将重点介绍系统的一个区域，即购物车系统。

这里有一个接口(interface)反转示例，PluralSite 用来解释在不考虑适当的依赖关系的情况下创建接口(interface)的典型趋势。

假设您有一个“BoxingMatch”类所依赖的 IKangaroo 接口(interface)。当您添加更多像 IMikeTyson 和 IJoeBoxer 这样的“拳击手”时，您现在拥有三个不同的接口(interface)，每个拳击手一个，“BoxingMatch”需要了解这些接口(interface)。 IKangaroo、IMikeTyson 和 IJoeBoxer 各只有一个具体实现，这意味着您甚至不需要这些接口(interface)(您不妨让 BoxingMatch 直接依赖于具体的 Kangaroo、MikeTyson 和 JoeBoxer 类)。此外，IKangaroo 或 IMikeTyson 的实现不止一种甚至没有意义。因此接口(interface)是不必要的，不会给架构带来任何值(value)。

在此示例中反转依赖关系将导致“BoxingMatch”定义其将要使用的类(Kangaroo、MikeTyson 和 JoeBoxer)将要实现的接口(interface)。因此，“BoxingMatch”将依赖于 IBoxer 接口(interface)，Kangaroo、MikeTyson 和 JoeBoxer 都将实现 IBoxer。这是倒置，它非常有道理。

现在，我的情况... CartController 构造函数注入(inject)了两个依赖参数，ICartService 和 IProductService)。 CartService 采用单个注入(inject)的构造函数参数 (ICartRepository)。 CartController 在 CartService 上调用 AddItem()，而 CartService 在 CartRepository 上调用 AddItem()。

ICartRepository 有两个实现:CartRepository(在主 Web 项目中)和 TestCartRepository(在 Tests 项目中)。 ICartService 只有一个实现。

我的问题:我的架构如何与上例中的类(class)相吻合？我真的不明白我的 CartController 与 CartService 的耦合度如何可能低于它已经耦合到 CartService 的耦合度。 Controller 只依赖于 CartService，而不是 ICartRepository。因此，我似乎无法通过让 CartController 定义 CartService 和 ICartRepository 将要使用的接口(interface)来反转控制，因为 CartService 和 CartRepository 是完全不同的层。我说得对吗？

下一级，同样的问题。 CartService 依赖于 CartRepository。上面的倒置原则在这里适用吗？或者我是否已经通过在 CartService 构造函数中要求 ICartRepository 注入(inject)参数来反转依赖关系？

所以我的问题是，我这样做“正确”了吗？

如有任何想法或建议，我们将不胜感激。

我的代码，供引用:

购物车 Controller :

//constructor
public CartController(ICartService cartService, IProductService productService)
{
    _cartService = cartService;
    _productService = productService;
}

public RedirectToRouteResult AddItem(Cart cart, int productId)
{
    var product = _productService.GetProduct(productId);
    if (product != null)
    {
        _cartService.AddItem(cart, product, 1);
    }
    return RedirectToAction("Index");
}

CartService(实现):

//constructor
public CartService(ICartRepository repository)
{
    _repository = repository;
}

public void AddItem(Cart cart, Product product, int quantity)
{
    //simplified for brevity
    var cartProduct = _repository.CartProducts().SingleOrDefault(cp => cp.CartId == cart.CartId && cp.ProductId == product.ProductId);
    _repository.AddCartItem(cartProduct);
}

购物车存储库(实现):

public void AddCartItem(CartProduct cartProduct)
{
    _context.CartProducts.Add(cartProduct);
    _context.SaveChanges();
}

Answer 1

您似乎错误地认为使用 IoC 的唯一原因是提供多个实现。事实上，这是使用 IoC 最没有用的理由之一。

通过使用 IoC 容器，您可以管理对象的生命周期(例如，通过使对象在单个 Web 请求的生命周期内存活)。

IoC 容器还处理递归依赖。如果您创建一个 IMikeTyson 并且 IMikeTyson 依赖于 IBoxingShorts，那么您不必实例化拳击短裤，它们是免费提供的。

所有这些都忽略了使用 IoC 的重要原因，那就是使单元测试更容易。通过使用接口(interface)，您可以为 BoxingMatch 的单元测试提供模拟 IMikeTysons，这样您就可以为 BoxingMatch 提供已知值，而不必在每次测试后重置数据库。

而且，IoC 和基于接口(interface)的编程还有大约 100 项其他好处。

我认为您过度考虑了购物车场景。你只需要传递你依赖的实例即可，不用太在意IoC的学术定义。