jdbc 最近的一些经验

以前从来没有关注过这些细节,所以犯了不少错误。在工作中获得了宝贵的经验,赶紧记录一下。

 

1.把实际逻辑部分写在dao中

要正确认识dao层和service层的关系。

因为不同的方法之间可能需要相互调用,所以我个人认为,最好把大的功能分解,分成单一的小的功能,分别写到dao层中,之后在service层中做多一次包装就好了。

就算功能本身不大,也可以这样写,让代码变得有层次。

举个例子:

我想要把三个搜索的结果一起输出出来,那么我就会把每个搜索在dao中写成单独的方法,然后在service层中写一个方法调用dao中的三个方法,做个包装,之后返回就可以了。

2.数据库链接关闭的问题

之前我的代码是这样进行关闭的:

问题就出在关闭连接这里:

看起来是把所有连接都关闭了,但是一旦resultSet.close();报错,就会直接跳到catch模块,之后的preparedStatement和connection都是关不掉的。同理,要是preparedStatement出问题,connection也是关不掉的,所以这里不能把三条关闭方法写在一起,一定要分开写。

这样就算前面的关闭出错,后面的还是能关。

3.写一个数据库连接管理类,重载关闭方法,专门用于关闭数据库连接

顺着第二点的思路,这样每次都写一堆try catch实在是太麻烦了。干脆写个方法专门关闭连接吧。

连接关闭的位置有讲究。往往由数据库操作和代码的位置共同决定。

比如说,select一般要在dao中关resultSet+preparedStatement,在service中关connection。update和insert往往只要在dao中关preparedStatement,在service中关connection。

特别是多个方法相互调用的情况,连接关闭更需要讲究。这点在这篇文章中也提到了:

http://www.xie4ever.com/2016/12/22/%E4%BB%8A%E5%A4%A9%E9%81%87%E5%88%B0%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/

所以我推荐写一个方法专门用于关闭数据库连接,因为传入的连接有多种情况,所以要用到重载:

最好顺便把日志记录也给做了。

在关闭数据库连接时,直接调用重载方法即可,会根据传入去关闭相应的连接。

4.数据库链接类型

有时候很容易犯这个错误。

在写Connection时,记住一定要使用java.sql.Connection包的Connection,不要使用

com.mysql.jdbc.Connection的Connection。

从源码可以看出,mysql包中的Connection也是继承sql包中的Connection:

实际使用时,DriverManager.getConnection()方法获取的Connection是sql包中的,

所以如果使用mysql包中的Connection,需要进行一次强转:

这样会导致什么问题呢?

如果一直使用Mysql数据库,这个链接基本上不会出问题。但是如果更换了别的数据库,因为这里有个强转,把通用的Connection对象转成了只有Mysql能使用的Connection对象,所以肯定会报错(别的数据库无法使用Mysql的Connection对象)。

如果一开始就使用sql包的Connection,就不需要强转了,移植别的数据库自然也是轻松愉快。

5.响应码/响应信息写成常量,直接从常量类中拿

我之前写在方法中的Return都是这样的:

每个方法,我都是这样返回的。

先不谈这样写有多重复,多麻烦。这样写有个什么问题呢?万一我要换响应码怎么办?万一我要换响应信息怎么办?难道一个个方法手工去修改吗?这样效率实在是太低了。

一种解决方法是单独写一个常量类,返回的时候直接调用常量类中的常量字段。以后修改的时候,我只需要改常量类中的某个字段就好了。

使用时就直接调用:

可以节省很多修改的功夫,而且所有常量写在了一起,很容易进行管理。不管常量值怎么拿怎么变,别的方法只是调用而已,会一直跟着变化,不仅容易修改,而且不会出错。

6.可以写一个读取类用于读取配置文件

顺着第4点的思路,我们写了一个配置类,对所有常量进行管理。除了这个容易管理和修改的优势之外,我们还可以很容易地在此基础上进行加强。

比如说,可以写一个读取类用于读取配置文件,专门从配置文件中获取常量值。这样我进行修改的时候,就不用进入类中进行修改,然后重新编译了。通过直接修改配置文件,就可以起到动态修改的效果,甚至能对运行中的服务的参数进行修改,而不用关闭服务,重新进行处理。

这种解决思路和spring中单独写一个配置类,把所有配置在xml文件中进行管理是一样的。

7.命名风格

最好使用相同的命名风格,我个人推荐全部使用驼峰命名。不要多种命名风格混杂,这会让别人看起来有些莫名其妙。

如果每个人都有自己的一套命名方法,那么一个系统里面的所有命名想必都是千奇百怪,各有不同,让读懂代码的成本变得很高,不利于开发和维护。所以遵守一个统一的命名风格非常非常有必要。

在这一点上我做得还是不够好。我现在还是习惯把实体类中的字段名写成数据库中的命名风格(全部都是小写,而且会有下划线)

比如说:

数据库中的name,在实体类中我会照样写成name(其实最好写成Name)。

数据库中的comp_name,在实体类中我会照样写成comp_name(其实最好写成CompName)

因为是习惯问题,最近我一直没注意去改。以后一定要把这个毛病改过来,不能我行我素了。

8.总结

宝贵的工作经验,一定要好好总结学习。谢谢师姐的帮助。