在一个 MVC 框架的项目中,应该在哪层开启数据库访问的事务啊? 
如果在 DAO 层的某个访问数据库的方法中开启事务就可能需要沉重的代码来实现事务管理,因为需要针对不同的请求,对不同的一个或多个表进行操作.而针对这些操作可能要生成不同的方法去实现. 

单独修改 A 表时需要一个方法,在该方法中开启事务,然后进行数据库访问操作 
当需要修改表 A同时又修改表 B时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作 
当需要修改表 A同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作 
当需要修改表 B同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作 

这样的设计显示是不好的! 
可是要是在调用DAO层之前的业务层中开启,似乎有违背的 MVC 结构 
请高人赐教应该 在哪 怎样 开启数据库访问的事务!

解决方案 »

  1.   

    应该是在DAO层实现统一的事务管理吧
    Spring有相应的实现.
      

  2.   

    应该是在DAO层实现统一的事务管理吧 Spring有相应的实现.
    关注一下...学习!
      

  3.   

    我和你遇到同样的问题,不过我还是在DAO层实现事务的控制的,如果在service层实现的话,会容易一点,不过觉得那样就增加了层与层之间的偶合度了.
      

  4.   

      在一个 MVC 框架的项目中,应该在哪层开启数据库访问的事务啊? ,扯蛋,呵呵
    那层也不是,如果非要找个出来,那也是所谓的M。  如果一个业务对象调用多个dao完成一个原子操作,你事务就没法做啦,所以不应当把事务加在dao层上。当然我的理论是建立在ctrl不会直接调dao,而是调业务层,业务层根据需要调用相应的dao(1个或多个),只要在业务方法中加上事务就好了。这样就避免了事务嵌套等问题。
      

  5.   

    我觉得事务是在service层实现,Dao做的只是简单的crud操作,如果事务加在Dao,很可能是对多张表的操作.
    那对一张表的操作怎么办呢.难道是调用这个加了事务的Dao?还是在做个Dao?
    这样肯定不是我们所想的.
      

  6.   

    在MVC框架中,与数据库交互不是由hibernate直接交互了吗?
    为什么还要开启数据库?