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

首先,我想澄清一下关于业务层的一些误解,因为你想使用Repository模式,你的设置是 Domain Driven Design的候选者,那么业务层实际上是[域模型( Entities and Value Objects,你设计你的实体和对象中面向对象方式的业务逻辑,以及应用层来协调域层的事务和操作以及命令,因此建议的体系结构将是这样的：

>演示文稿(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)]中实现,用于协调,访问存储库和应用程序的事务层是地方.