在一个 MVC 框架的项目中,应该在哪层开启数据库访问的事务啊?
如果在 DAO 层的某个访问数据库的方法中开启事务就可能需要沉重的代码来实现事务管理,因为需要针对不同的请求,对不同的一个或多个表进行操作.而针对这些操作可能要生成不同的方法去实现.
{
单独修改 A 表时需要一个方法,在该方法中开启事务,然后进行数据库访问操作
当需要修改表 A同时又修改表 B时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
当需要修改表 A同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
当需要修改表 B同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
}
这样的设计显示是不好的!
可是要是在调用DAO层之前的业务层中开启,似乎有违背的 MVC 结构
请高人赐教应该 在哪 怎样 开启数据库访问的事务!
如果在 DAO 层的某个访问数据库的方法中开启事务就可能需要沉重的代码来实现事务管理,因为需要针对不同的请求,对不同的一个或多个表进行操作.而针对这些操作可能要生成不同的方法去实现.
{
单独修改 A 表时需要一个方法,在该方法中开启事务,然后进行数据库访问操作
当需要修改表 A同时又修改表 B时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
当需要修改表 A同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
当需要修改表 B同时又修改表 C时又需要一个方法.在该方法中开启事务,然后进行数据库访问操作
}
这样的设计显示是不好的!
可是要是在调用DAO层之前的业务层中开启,似乎有违背的 MVC 结构
请高人赐教应该 在哪 怎样 开启数据库访问的事务!
Spring有相应的实现.
关注一下...学习!
那层也不是,如果非要找个出来,那也是所谓的M。 如果一个业务对象调用多个dao完成一个原子操作,你事务就没法做啦,所以不应当把事务加在dao层上。当然我的理论是建立在ctrl不会直接调dao,而是调业务层,业务层根据需要调用相应的dao(1个或多个),只要在业务方法中加上事务就好了。这样就避免了事务嵌套等问题。
那对一张表的操作怎么办呢.难道是调用这个加了事务的Dao?还是在做个Dao?
这样肯定不是我们所想的.
为什么还要开启数据库?