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

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

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

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

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

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

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

解决方法

>演示文稿(MVC)[OrderView,OrderPresentationModel,OrderController]
>申请[OrderService]

>使用UnitOfWork(Transactions)和存储库来执行域逻辑
> 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是一个好主意吗？交易控制应该在哪个阶段发生？在我看来,但如何避免这种情况？

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

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

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

3)UnitOfWork类与业务层类相同吗？
– 如果是这样,我们是否将工作单元包含在包含业务逻辑方法的其他类中？

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

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!