容器，Connection，事务，DAO模式（侧重JDBC分析） 转载

DAO（Data Access Object）模式可以看成是Data Accessor模式 与 Active Domain Object模式；前者实现了数据访问和业务逻辑的分离，后者实现了业务数据的对象化封装。结合在一起即是对数据访问的封装。

DAO模式往往用于数据库的JDBC操作中，最主要的应该就是事务。JDBC 事务是用 Connection 对象控制的，默认的事务模式是事务自动提交，如果采用“手工”管理，需要把Connection对象的自动提交功能设置为false，即conn.setAutoCommit(false)，在提交时使用conn.commit();才正式提交事务。

DAO的职责：每个类对一个数据表进行维护，即增/删/改只针对一个表，查可以连接多个表并返回业务对象（Business Object）。

问题就出现在DAO既然只是针对一个数据表进行维护的，但在一个业务逻辑操作中，业务对象可能需要好几个DAO来共同服务。

一个较好的原则就是一个业务对象的一次具体操作最好能在一个事务中完成。抛开应用服务器提供的可能的JTA不谈，不妨把Connection的获得放到业务对象的方法中，在每个DAO的方法中增加Connection作为参数；在业务对方的方法体最后关闭这个连接。这样，就形式上与多个SQL语句组合在一个事务中有相同的效果。

另外，对于一些业务对象，其并不涉及多个DAO操作，是否还需要这样来做呢？当然这样做也无可厚非，但不妨在DAO的方法中同时提供有Connection和无Connection参数的两种方法；这样就比较容易处理了。

虽然JTA及其容器的事务声明方式更简单，但是如果在没有提供JTA功能的容器比如Tomcat下运行，这样也不失为一种解决办法.

写完了，在封装一些方法时，突然想起来了，如果对连接用的是连接池，Connection创建、关闭好像没有什么问题哦，也就不用上面的方式了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16629/viewspace-78750/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16629/viewspace-78750/