根据这篇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)]中实现,用于协调,访问存储库和应用程序的事务层是地方.
