c# - 新 MVC3 项目中的 InversionOfControl

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

这是一个接口(interface)反转示例 PluralSite 用来解释创建接口(interface)而不考虑适当依赖项的典型趋势。

假设您有一个“BoxingMatch”类所依赖的 IKangaroo 接口(interface)。当您添加更多“拳击手”(如 IMikeTyson 和 IJoeBoxer)时，您现在拥有三个不同的界面，每个拳击手一个，“BoxingMatch”需要了解。 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(在测试项目中)。 ICartService 只有一个实现。

我的问题:我的架构如何与上述示例中的类(class)相结合？我真的看不出我的 CartController 与 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();
}

最佳答案

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

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

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

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

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

我认为你想多了你的购物车场景。你只需要传递你依赖的实例，不用太担心IoC的学术定义。

关于c# - 新 MVC3 项目中的 InversionOfControl，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/8396232/