DAO的困惑－－事务处理

我越来越困惑
先看看我的示例代码


方法1：
ADAO{

methodA(){

Connection con=ConnectionPool.getConnection();
//do some thing
methodB();
con.close();

}

methodB(){

Connection con=ConnectionPool.getConnection();
//do some thing
con.close();

}

}

方法2：
ADAO{

methodA(){

Connection con=ConnectionPool.getConnection();
//do methodA thing
//do metnodB thing
con.close();

}

methodB(){

Connection con=ConnectionPool.getConnection();
//do some thing
con.close();

}

}


方法3：
ADAO{

methodA(){

Connection con=ConnectionPool.getConnection();
//do methodA thing
methodB2(con);
con.close();

}

methodB(){

Connection con=ConnectionPool.getConnection();
methodB(con);
con.close();

}

methodB(Connection con){

//do methodB thing

}


}

就拿上面的代码来说，methodA和methodB()都可以被外界单独调用,在方法1中我们要完成methodA()，要创建两个Connection，且不说资源消耗,最大的问题是methodA和methodB不在一个Connection中而不好做事务化.

方法2虽然可以解决methodA和methodB的事务问题,但却在methodA中重复了一遍methodB的代码,个人感觉不好.

方法3虽然野可以解决事务问题而且可以重用代码,但是问题就是要多定义一个方法,如果所有的方法分开两个方法实现,DAO中的方法就加倍了,也觉得不好.

请问那种方法比较好呢,或者有更好的解决?

非常经典的现实例子。

其实这也就是为什么要使用AOP的缘故，在目前解决方案中，AOP可以漂亮地解决这个问题。

下面以AspectJ为例子，当然使用其他AOP如Spring或JBoss 3.0更简单，JBoss 3.0相当于使用EJB，缺省支持，无需Spring那样专门配置事务语句。

你的DAO代码写成如下：


ADAO{
  methodA(){
   Connection con=ConnectionPool.getConnection();
   //do methodA thing
   methodB2(con);
   con.close();
  }
  methodB(){
   Connection con=ConnectionPool.getConnection();
   methodB(con);
   con.close();
  }
  methodB(Connection con){//do methodB thing}
}


public aspect Lock {

　　......
Connection con;

　　public pointcut writeOperations():
　　　　execution(public boolean ADAO.methodA()) ||
　　　　execution(public boolean ADAO.methodB()) ) ;


　　before() : writeOperations() {
//开始事务机制　advice body
　　　　con=ConnectionPool.getConnection();
　　}

　　after() : writeOperations() {
//结束事务
　　 　 con.close();
　　}

　　......
}

在不使用AOP情况下，你的第三个方案是比较合理的，建议将
methodB(Connection con){//do methodB thing}和mehtodA中主要业务逻辑单独打包成一个类。

DAO中打开con肯定不行,只能在ejb中打开，然后将con传入DAO,由ejb的机制来保证事务

我一般用IOC解决类似问题，请大家讨论优缺点

ADAO{
methodA(){ Connection con=ConnectionPool.getConnection(); //do methodA thing methodB2(con); con.close(); } methodB(){ Connection con=ConnectionPool.getConnection(); methodB(con); con.close(); } methodB(Connection con){ //do methodB thing } }

我一般用IOC解决类似问题，请大家讨论优缺点

ADAO{
methodA(Connection conn){
//do methodA thing
}
methodB(Connection conn){
//do methodB thing
}
}
ADAOManager{
methodDoAandB(){
Connection con=ConnectionPool.getConnection();
methodA(con);
methodB(con);
con.close();

}

}

Dao只能使用资源，而不应该管理资源。

也就是说，Dao可以使用Connection，但不能维护它----生成和关闭。

我觉得antzl提供的
IOC解决类似问题，很简洁，我还看的懂其它的我觉的就郁闷了！

我认为事务不要有dao来处理。
应该由业务方法处理


DAO模式是多余的麻烦。哪怕用hibernate，我也不参进所谓的dao

搞笑，你还使用jdbc，落后了。


不用JDBC用什么!基本的东西还不是JDBC不要告诉我!是用mapping之类的

小弟也发表一下遇见哈。

其实，我觉得，有些东西未必简单的方法就不好，复杂的东西就一定更适用。要看具体的情况。
各种各样的技术无非就是发现简单或者底层的东西不好用了，就在上面包多一层，再不好用了，就再加一层。但是有时候这样带来的代价就是使使用更复杂化，灵活度更低，所以具体使用什么技术来实现不好说哪个好，哪个不好。

我现在也很疑惑

以前一直用JDBC编写的,没有用什么O/R映射的框架
现在是不是落伍了???

在一些很复杂的操作环境下直接使用dbc的反而更方便，跨数据库间的jdbc其实操作的差异是很小的，基本上以自行解决。看看Jive4.0，底层数据操作较之前有根本的发展，但仍然是用Jdbc来操作数据库，实际就是为了获得最大的灵活性。

下页