业务逻辑层的设计(三)——事务的考虑
本文讨论面向对象程序语言中,事务管理的思想。
注意:本文代码中涉及到事务管理的上下文,是我探索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