业务逻辑层的设计（三）——事务的考虑

本文讨论面向对象程序语言中，事务管理的思想。

注意：本文代码中涉及到事务管理的上下文，是我探索ORM原理时自制的上下文，读者只要看着去理解他的意思就好了，实战当中我用的是另外开源框架中的上下文。

事务管理应该放在哪一层做

事务的开始与提交应该放在哪里呢？业务逻辑层还是数据访问层？

我以为，数据访问层需要，业务逻辑层也需要。

这样业务层就可以组合仓储的数据库操作，随意组合成一个事务，而仓储才可以被重用。

那么具体如何实现呢？

业务层的事务,这里引入了System.Transactions命名空间，userRep.Save(user2);这段就是刚才看到的，包含了一个事务的仓储，

执行tx.Complete();才会走完这个事务，如果在using中出现了异常，那么所有事务都将回滚。

        [Test]
        public void TranTest()
        {
            IDataContext context = DataContextFactory.GetDataContext();
            Department dept = context.Get<Department>(1);
            User user1 = new User() { LoginName = "adama1", Name = "adama1", Password = "123123", Department = dept };
            User user2 = new User() { LoginName = "adama2", Name = "adama2", Password = "123123", Department = dept };
            IUserRepository userRep = RepostoryFactory.GetFor<User>() as IUserRepository;
            using (TransactionScope tx = new TransactionScope())
            {
                context.Add(user1);
                userRep.Save(user2);
                tx.Complete();
            }
        }

注：使用TransactionScope可能会将事务升级为分布式事务。

在Java EE中，我见过事务管理出现在DomainService，也见过它出现在MVC的Controller，SpringMvc整合Hibernate后以注解的形式出现。

然而，在.NET中，也有MVC+Spring.NET+NHibernate，只不过与微软MVC整合得不完全，需要手动为每个控制器写XML配置，好在MVC提供我们扩展的功能，我们可以利用反射机制免去手动写XML配置。

现在我已经完成了整合，这不是演习代码，如下图：

Repository

Service

MVC Controller

UI