上一篇博文总结了一下mybatis的入门,接下来就要开发dao方法了,这篇博文主要总结一下mybatis中原始dao开发的方法,最后并总结一下原始dao开发方法的弊端。mybatis中dao开发应该使用mapper代理的方法,这将在下一篇博文中介绍。
原始dao开发思路比较简单,写个dao接口和dao实现类即可。需要向dao实现类中注入sqlSessionFactory,在方法体内通过sqlSessionFactory创建sqlSession。为什么在方法体内创建呢?因为mybatis中sqlSession是线程不安全的。如果在方法外面以成员变量的方式创建,可能会引发线程安全问题。下面总结一下原始dao开发的步骤(dao的方法跟上一节入门程序中的方法一致):
1. 写UserDao接口
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
2. 写UserDaoImpl实现类
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
从UserDaoImpl实现类中可以看出,首先SqlSessionFactory需要注入进来,这里通过构造函数来注入,传个SqlSessionFactory进来即可完成注入。另外,sqlSession都是在具体方法内部创建的,没有将sqlSession放到外面,因为在方法内部,相对于每个线程是独立的,不会引起线程安全问题。至于每个方法内部的实现,和上一节的入门程序逻辑一样。
3. 写单元测试UserDaoImplTest
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
从JUnit测试程序中可以看出,通过@Before注解,将SqlSessionFactory在测试方法执行之前初始化好,然后在测试方法中,直接通过构造函数传进去即可,这就和上面的UserDaoImpl实现类接上了。然后测试一下添加用户即可。
4. 原始dao开发存在的问题
从上面的代码中,可以很明显的看出原始dao开发方式有以下弊端:
- dao接口实现类方法中存在大量重复代码,从设计上来看,应该抽取。
- 调用sqlSession方法时,将satement的id硬编码了,即类似于”test.findUserById”这种,都写死了。
- sqlSession的方法中,要求传入的参数是Object类型的(泛型),也就是说如果我传错了参数,编译不会报错,执行的时候才会报错,不利于开发。
这些都是原始dao开发方式中存在的问题,在了解了原始dao开发方式的问题后,再来使用mapper代理开发dao,就可以形成鲜明的对比了。这篇博文就总结到这。