数据持久层漫谈

从开发人员的角度看数据持久层

1.编写SQL数据库语言SQL通过JDBC驱动操作数据库对象

     最原始的操作数据库模式是：编写数据库语言SQL通过JDBC驱动操作数据库对象。处于这模式时，开发人员需要编写大量的SQL来完成数据库数据的操作，这个时候SQL语句就会很多，怎么对这些SQL语句进行管理是一个很重要的问题。

     最开始很多人都会把SQL语句直接写在Java代码中，这样SQL语句就会分散在Java代码的各个地方，Java和SQL语句就会充斥在一起，不利于代码的可读性和维护，以后修改SQL需要在整个Java代码中查找。

     后面发展到了把所有SQL语句统一放在一个地方，一些人就会想到那把所有SQL语句按照功能放在一个个类似于常量的类中不是可以了吗？再通过变量进行获取就可以了。这样做会有问题吗？这样做可以解决前面的提出的问题，但这样又有新的问题，是什么问题呢？假如SQL语句很长，用Java的一行代码来表示的话，会不直观，如果放成多行的话，必须使用＋号表示，这样影响运行效率；假如我们想改SQL语句，就必须改Java类代码，改完了就必须重新编译，然后再重新发布。能不能有改SQL语句不需要重新编译？

     目前的做法是将SQL语句放在数据的持久媒介中，可以是XML文件，也可以放在数据库中。如果放在XML文件，那么就得有一个XML文件的SQL读取器来专门处理加载SQL语句的工作。如果放在数据库中，SQL语句的版本管理是一个问题，放在XML文件中我们还可以通过版本管理工具（比如SVN）来管理SQL的版本。接下来我们就会遇到一个新的问题，在开发过程中我们不想为了添加、修改或者删除SQL语句而重启WEB容器，这样一停一启比较费时间，影响开发效率。

2. 通过表名来操作数据库表数据

     如果什么都需要编写SQL语句来操作数据库完成业务逻辑，那一个系统的SQL语句会很多，一个开发人员需要编写的SQL语句也是一大堆，这里提出一个问题，能不能不写SQL语句就可以完成数据库表数据操作呢？这样开发人员也就可以大量减少编写SQL语句的工作。

     开源框架Hibernate就是一个很好的例子，Hibernate通过数据库表结构和类的结构的映射来进行翻译工作的，将对象转换为SQL语句去数据库执行，或者将查询的结果翻译成对应的类实例。那么最直接的方式是通过数据库表名来操作该表的数据，比如保存时，我们调用一个方法传入表名和一个字段值对（比如Map），那么该方法会根据这些传入的参数信息自动拼凑出一条插入SQL语句出来并执行。这样开发人员就不需要去编写重复性的SQL语句了，想要操作哪个表的哪条记录的哪个字段值都很轻松就可以达到了。

3. 通过对象来操作数据库表数据

      前面提到了根据表名来操作数据库表数据方式，这种是最直接的方式，在面向对象的语言中，很多时候我们都会通过操作对象来操作对应的表记录，开发人员不用关心数据库是怎么样的，只需要关心有哪些业务对象，完成一个业务功能需要操作哪些业务对象。Hibernate已经实现了这种方式了，但还不够简单，Hibernate怎么知道表和类的映射关系呢？以前是通过一个XML配置文件来映射的，现在通过注解来映射。都得由开发人员来主动的表示。

     能不能有一种默认的映射方式呢，开发人员就不需要去表示他们的映射关系，比如USER_INFO表对应UserInfo类，USER_ID字段对应于userId属性。如果有特殊的，可以通过注解或者其他方式来解决问题。