《深入浅出Hibernate》：Java持久化的演进1

以前看过一些持久化的封装代码，但并没有完全理解其设计思想和要义，今天看了《深入浅出Hibernate》的章节，有种拨云见日，豁然开朗的感觉。今天就写篇博文梳理下演进过程，希望能帮助各位更清晰地理解持久化的解耦思想吧。

这里我们有一个需求，查询客户A的银行账户余额，代码如下：

上面的代码是标准的JDBC查询操作。

想一想：查询完成后，需要释放哪些资源？为什么？

这里不展开讲了，有兴趣的可以参考这边文章

连接池connection关闭后Statement和ResultSet未关闭的问题

http://k1121.iteye.com/blog/1279063

问题1：如果数据库的登陆用户名和密码泄露，需要重新设置，怎么搞？

在代码里查找，挨个修改？。。。这不是个好方法，10个还好，100也能接受，如果有成千上万的地方需要修改呢？

演进1：使用配置文件

像下面这样，这样就能一改全改，将容易变化的数据提取到配置文件里，大家都从配置文件里读数据。

问题2：出于性能提升，需要使用使用连接池，怎么搞？

关于连接池的原理，可以参考下这边博文

谈谈数据库连接池的原理

因为有多种数据库连接池技术实现，说不准哪天因为技术瓶颈或性能方面的考虑，又要切换数据库连接池技术实现。

演进2：增加一个DB工具类

像下面这样，这样我们就隔离了获取Connection和释放Connection的变化，如果后面需要修改，我们只需要修改DBHelper类即可。

问题3：业务逻辑与数据访问耦合

耦合最直观的感觉或是认识就是业务逻辑和数据访问代码写到了一块，像下面这样，我们看到业务逻辑和数据库操作混合在了一起。这样做问题很多，比如获取balance的查询语句变了，就需要挨个修改代码中调用的地方，做业务逻辑的也需要兼修维护数据库访问的代码等等。

演进3：引入DAO模式（Data Access Object）

这个模式实现了数据访问和业务逻辑分离，并且对象化封装了业务的数据。

可以对比下前后的代码，访问数据库的操作直接有CustomerDAO来做，并且将结果封装在了Customer类里面。也就是说，数据库不管是以后优化也好，更改也好，和客户端的操作已经隔离了，不会影响到客户端的代码。客户端只需要维护业务逻辑就好。

Customer的代码示例如下

还没演进完，今天先到这儿，明天继续啊^_^