2010-03-23 56 views
3

这个问题与我的ASP.NET MVC 2开发有关,但它可以应用于任何MVC环境和逻辑应该到哪里的问题。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应付款处理进行处理:

  1. 在控制器?
  2. 通过存储库?
  3. 其他地方?

回答

6

你想3.其他地方。

把它放在类库中。创建一个包含付款处理所需的所有方法的界面。使方法通用。把具体的细节放在接口的实现中。然后从该界面派生您的付款处理服务。这给你的选项,包括测试和多付款处理器。

看看MVC店面视频http://www.asp.net/learn/mvc-videos/。可能是视频#23(第22部分)。自从我观察这些以来已经有一段时间了。

+0

@ 37Stars。这些视频很好。谢谢你指点我。 – Keltex 2010-03-23 18:46:58

1

我建议在Business Object中构建这个逻辑,然后从Controller中调用它。

例如创建一个PaymentBO类(静态或其他方式),所以你可以调用PaymentBO.ProcessPayment(...)

1

Model要解决这个问题,因为它是负责直接使用的部件(并保持你的数据的一致性。具体来说:

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

+0

的模型只是传递给视图的对象。我不认为商业逻辑应该放在模型上。也就是说,我已经看过它一百次...... – hunter 2010-03-23 15:00:38

+1

@Hunter业务逻辑不应该在你的*视图模型*中,但它应该在你的域模型中,如果你有一个。 – Ryan 2010-03-23 15:19:12

+0

我不同意,如果你认为大多数模型不过是域对象反正(ASP.NET MVC类模糊两个,这是令人沮丧的)。我尽量保持我的Domain对象(例如表示数据表的对象)和我的Model对象(可以是Domain对象或Domain对象集合或其他)尽可能干净,并使用BO作为这种类型的东西... – hunter 2010-03-23 15:24:58

1

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

1

这是一个建筑问题。您应该为整个系统决定实施业务逻辑的方法是否适合您的特定情况。这些方法最好在Martin Fowlers PoEAA中描述(在我看来)。主要有三种型态:

  • 交易脚本 - 具有用于处理特定事务的单独对象的装置
  • 活性记录 - 具有简单的逻辑装置直接放置在O/RM-映射表表示对象
  • 域模型 - 指具有丰富的唯一代码模式,即负责解决问题

要选择主要取决于您的系统复杂程度。我描述的模式是根据它们解决复杂问题的潜力来排序的(DDD最擅长处理复杂的问题,但它本身也引入了一些“意外的”复杂性)。

1

由于已经有关于存储库模式的参考资料,因此您可以详细说明域驱动设计(如Szymon所述)。

如果你这样做,你会需要一个服务层,然后与它下面的丰富模型交谈。 这里是伪代码

在付款控制器:

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

在付款服务

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

    // more ... 

}