Question

这个问题与我的ASP.NET MVC 2开发有关，但它可以应用于任何MVC环境以及逻辑应该去哪里的问题。

因此，假设我有一个控制器，可以进行在线支付，例如购物车应用程序。我有接受客户信用卡信息的方法：

public class CartController : Controller
    CartRepository cartRepository = new CartRepository()

    [HttpPost]
    public ActionResult Payment(PaymentViewModel rec)
    {
        if(!ModelState.IsValid)
        {
            return View(rec);
        }

        // process payment here

        return RedirectToAction("Receipt");
    }

在评论process payment here处，应处理付款处理：

在控制器中？
通过存储库？
其他地方？

Answer 1

你想要3.别的地方。

将它放在一个类库中。创建一个具有付款处理所需的所有方法的界面。使方法通用。将具体内容放在接口的实现中。然后从该界面派生您的付款处理服务。这为您提供了包括测试和多个支付处理器的选项。

查看http://www.asp.net/learn/mvc-videos/处的MVC店面视频。可能是视频＃23（第22部分）。我看了这些已经有一段时间了。

Answer 2

我建议在业务对象中构建此逻辑并从Controller中调用它。

例如创建一个PaymentBO类（静态或其他），这样你就可以调用PaymentBO.ProcessPayment（...）

Answer 3

Model应该处理这个问题，因为它是负责直接处理（并保持数据一致性）的组件。具体做法是：

模型是应用程序运行的数据的特定于域的表示。

Answer 4

如果你正在使用存储库模式，那么我建议创建一个服务对象来处理任何付款，并让你的控制器调用它。

Answer 5

这是一个架构问题。对于整个系统，您应该决定实现业务逻辑的哪种方法适合您的特定方案。这些方法在Martin Fowlers PoEAA中得到了最佳描述（在我看来）。主要有三种模式：

交易脚本 - 表示有一个单独的对象来处理特定交易
活动记录 - 表示将简单逻辑直接放在O / RM映射表中的表示对象
域名模型 - 意味着拥有丰富的仅代码模型，负责解决问题

选择主要取决于您的系统复杂程度。我描述的模式是按照它们解决复杂问题的潜力排序的（DDD最擅长复杂的东西，但它本身也会引入一些'偶然的'复杂性）。

Answer 6

由于已经有关于存储库模式的引用，您可以详细说明Domain Driven Design（如Szymon所述）。

如果你这样做，你将需要一个服务层，而服务层又与它下面的丰富模型进行对话。这是伪代码

在付款控制器上：

var paymentDetails = mapFromViewModel(rec)
PaymentService.Pay(paymentDetails)

在付款服务上

void Pay (PaymentDetails paymentDetails)
{
  // leverage on rich model behavior here
  if (User.IsHaveEnoughMoney)
  {
    Cashier.Pay( ... )
  }

  // more ...

}

MVC架构问题 - 付款处理应该在哪里？

6 个答案: