你的位置:首页 > ASP.net教程

[ASP.net教程]面向服务开发中三层架构中事务单元的生命期管理


    经典的三层分层结构,控制层(Control),服务层(Service),持久层(Repository)应用广泛,在面向服务(SOA)的架构中,配合DI、IOC实现开放灵活的技术架构。

    SOA中,Respository面向数据访问,提供访问数据库、文件、或其他业务接口提供持久能力。Service面向业务,提供访问业务功能的接口,使用领域模型描述业务需求,方便产品人员、需求人员和客户沟通理解业务流程。最后,Control面向业务流程整合,提供基于事务的需求实现。

    事务,用需求来讲,就是事情要么成功,要么就是没有变化,不能有中间的不正常状态。在数据库事务中,数据库产品已经提供了数据库事务,来保证数据修改删除的事务性,电商支付体系中,也提供了预扣费,消费来保证事务性。

    既然事务这么重要,我们应该在哪里控制事务呢?控制层、服务层还是持久层?

    按照分而治之的思路,应该是持久层服务持久层的事务,服务层控制服务的事务,控制层控制这个事务,层层管理,内层事务自治的同时,服从外层事务。互相配合,协同工作完成。

    理想中的无事务控制流程和生命期是这样的,如下图:

QQ截图20151028213347

    理想中的有事务的流程是这样,简图如下:

index

但是因为Unity/Spring的系统中,IOC控制着对象的生命周期,图中LifeScope对象对程序员不可见,便会引发集中常见的问题。

1. 完全无视生命期,不进行回收

    这种情况下,程序的反应是Respository每次创建数据库连接,直到数据库连接数过多,造成系统宕机。(几乎没人使用的系统除外)

2. 每次创建生命期,等框架自动回收

    此时分两类,一种对框架比较了解,能正确配置使用并观察到生命期内对象的回收,此时没有问题。第二种就悲催了,认为框架就应该做好了回收,完全自动化回收,此时完全看抄的度娘上人什么水准了,差的情况,一样会数据库连接数过多,造成系统宕机。

3. 单例服务改为每次创建,降低性能

    有时,为了解决单例服务产生的数据库连接问题,连接上已经启动事务等问题,有人把应该为单例的服务配置为每次创建,想依靠服务每次创建,自动创建不懂的数据库连接。姑且不说服务是不是应该单例存在,这样每次创建,就会造成极大的性能开销。