ASP.NET MVC3 - 3层设计 - 事务控制和业务层设计问题

Question

我正在设计一个ASP.NET MVC3应用程序,我希望在3层架构中明确区分关注点.我使用Fluent NHibernate作为ORM,Repository模式与NHibernate映射的实体一起使用.我想添加一个具有Unit Of Work模式的适当业务层,保留MVC部分仅用于表示(通过使用通过业务层映射到nHibernate实体的ViewModels). 本文很好地描述了组合的3层和MVC架构.

根据这个MVC +工作单元+存储库文章,我没有看到业务层的明显区别.工作单元类为每个存储库类型提供强类型的getter,它看起来适合业务层.但是,它暴露了一个Save方法,我认为它会转换为使用nHibernate的BeginTransaction和CommitTransaction方法.这引出了一些问题:

1)将事务控制暴露给MVC是一个好主意吗？交易控制应该在哪个阶段发生？在我看来,MVC不应该对交易负责,但如何避免这种情况？

2)是否应该有一些自动处理交易的方法？ 此ActionFilter实现是半自动的,但事务控制显然位于MVC部分,而不是业务层.

3)UnitOfWork类与业务层类相同吗？
- 如果是这样,这是否意味着我们可以在其中添加自定义业务逻辑方法？
- 如果没有,我们是否将工作单元包含在包含业务逻辑方法的其他类中？

我感谢任何想法或例子.谢谢.

Answer 1

首先,我想澄清一下关于业务层的一些误解,因为你想使用Repository模式,你的设置是域驱动设计的候选者,那么业务层实际上是[域模型(实体和值)对象,你的设计在实体和对象)面向对象的方式你的业务逻辑和应用层来统筹交易和操作和命令域层],所以建议架构将是这样的:

• 演示文稿(MVC)[OrderView,OrderPresentationModel,OrderController]
• 申请[OrderService]
  • 使用UnitOfWork(Transactions)和Repositories来执行域逻辑
  • DTO [OrderDTO,CustomerDTO]
• 域
  • 实体和价值对象[订单,客户,LineItem,地址]
  • 存储库接口[IOrderRepository,ICustomerRepository]
  • (可选)工作单元接口[IUnitOfWork]
• Infrastructure.DataAccess(使用ORM或数据访问技术)
  • 存储库[OrderRepository,CustomerRepository]
  • (可选)工作单元[UnitOfWork]
• Infrastructure.Common
  • 记录
  • 公用事业

示例场景:

[演示] OrderController:

 _orderService.CreateOrder(OrderDTO);

[应用] OrderService:

 _unitOfWork.BeginTransaction();
 var customer = _customerRepository.GetById(orderDTO.CustomerId);
 var order = new Order() { Customer=customer, Price=orderDTO.Price, ... }
 _orderRepository.Add(order);
 _unitOfWork.Commit();

关于你的问题:

1)将事务控制暴露给MVC是一个好主意吗？交易控制应该在哪个阶段发生？在我看来,MVC不应该对交易负责,但如何避免这种情况？

不,我宁愿在应用层中将其分开,以使设计灵活,以支持不同的演示.

2)是否应该有一些自动处理交易的方法？此ActionFilter实现是半自动的,但事务控制显然位于MVC部分,而不是业务层.

在应用程序层中使用事务.

3)UnitOfWork类与业务层类相同吗？ - 如果是这样,这是否意味着我们可以在其中添加自定义业务逻辑方法？ - 如果没有,我们是否将工作单元包含在包含业务逻辑方法的其他类中？

不,这只是将任务分组到事务中的一种方法.业务逻辑实际上封装在实体中,如果逻辑与一个实体无关,则应在域服务[TransferService.Transfer(account1,account2,amount)]中实现,用于协调,访问存储库和应用程序的事务层是地方.