数据持久层漫谈

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

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属性。如果有特殊的,可以通过注解或者其他方式来解决问题。

相关推荐