funcreal小灶：通用数据库连接类的可行性

新手都有过这样的经历：封装数据库操作。把Statement的功能封装到一个看起来像Connection的对象里面，并且将数据库操作简化。那么真的简化了吗？你有没有发现，你封装好的这个类几乎在每个工程中都要进行一些修改，几乎它总是不能像上一个工程中那样表现良好？你的这个类可以进行事务处理吗？可以产生一个可滚动可更新的结果集吗？可以对存储过程进行访问吗？可以进行参数化查询吗？好了，你的这个数据库工具类现在应该已经无地自容了。没错，当我封装来封装去，最后发现它是如此脆弱的时候，我开始思考了，这个封装真的有必要吗？它到底给你的工程带来了什么？我是不是有时候似乎为了迎合它来变更我的应用？  
  我的结论是：查询的方式和查询的对象与业务逻辑紧密耦合，不适合封装成通用工具类。  
  具体到一个例子上就是，假如你有一个工具类叫做DBUtil，那么他不应该提供这种操作：  
  DBUtil.loadConfig();  
  ResultSet   rs   =   DBUtil.executeQuery(sql);  
  而应该提供这种操作：  
  Connection   conn1   =   DBUtil.getDBName1Conn();  
  Connection   conn2   =   DBUtil.getDBName2Conn();  
  PreparedStatement   st   =   conn1.prepareStatement(sql);  
  …  
  这就足够了。我们只需要为每个工程配置一个DBUtil，并且它只负责提供数据库连接。试图为所有工程提供一个封装了查询的通用连接类几乎都是徒劳的。如果可行，JDBC就不会被设计成现在的样子了。  
   
   
  希望大家都发表自己的观点，给社区添加的真正有用的东西，谢谢！ 问题点数：20、回复次数：4Top

1 楼jFresH_MaN（十一月的萧邦－夜曲）回复于 2005-12-16 09:44:28 得分 15

为了回复，特地登陆上来，20分少了点。。  
   
  我到现在就做过一个和数据库相关的项目，当时什么也没封装，当时用的是weblogic的数据源。  
  你说的是有一定道理。不过我觉得事实上要封装是可以的，因为可能有的时候需要你上面所说的那些功能，有的时候就只是简单的查询。  
  所以我觉得可以这么做。  
   
  构造一个DBUtil，这个类提供一系列静态方法，那么他可以返回Connection对象，可以返回Statement对象，可以直接提供执行sql语句的方法.这样的话，前者就可以当使用者自由使用事务，存储过程之类的。后者就提供了一个简单的查询数据库的入口。  
   
  话又说回来了，现在大型项目里面都使用Hibernate或者Ibatis这些数据持久化框架，可能很多人都会花时间琢磨这个了。。Top

2 楼miaoliujun（傲龙）回复于 2005-12-16 09:48:17 得分 5

如果是这样，你可以利用现成的框架来解决这个问题，持久性框架对这个处理的都比较好的。除非你自己也想开发一个出来，否则我觉得利用现有的是一个不错的选择:)  
  比如hibernate，对数据库的操作部分你可以利用工具自动生成，时间长了，你可能都能自己做一个适合自己的模板Top

3 楼funcreal（为中华之崛起而编程）回复于 2005-12-16 09:50:24 得分 0

谢谢哦！  
  我觉得我和你的观点是基本相同的。  
   
  “构造一个DBUtil，这个类提供一系列静态方法，那么他可以返回Connection对象，可以返回Statement对象，可以直接提供执行sql语句的方法.这样的话，前者就可以当使用者自由使用事务，存储过程之类的。后者就提供了一个简单的查询数据库的入口。”  
   
  我认为后者是和业务联系较为紧密的，如果真的提供一个通用类也不是不可以，只是很难想象他是一个多么庞大的家伙。Top

4 楼funcreal（为中华之崛起而编程）回复于 2005-12-16 09:53:27 得分 0

大家都提到了框架。用框架当然就没有讨论的必要了。我想大家多从底层讨论一下。这样可以提高对“面向对象”的认识，而且扩展开来的话，并不是所有的事情都有框架来支持。或许真的有一天，我要写自己的框架呢。Top

相关问题

• 数据库
• 框架
• 查询
• 连接
• 存储过程
• sql
• 封装
• dbutil
• 通用
• 类

• 帖主：funcreal
• jFresH_MaN
• miaoliujun

• CSDN Java频道
• Java类图书
• Java类源码下载