原始dao层开发

    在我们用mybatis开发了第一个小程序后,相信大家对于dao层的开发其实已经有了一个大概的思路了。其他的配置不用变,将原来的test方法,该为dao的方法,将原来的返回值,直接在dao层进行一下接收就可以了。依然是老一套,先是大框架,然后写配置文件及UserMapper.xml文件这一系列的操作。如果不明白的,请参考本人博客《入门第一个程序》。

    我们需要做的就是,首先建立一个会话工厂(SqlSessionFactory),然后用会话工厂创建会话(SqlSession)。然后通过读取配置文件得到sql语句,执行,然后返回数据给dao层的对象。具体操作如下

    首先,在原来的基础上创建一个dao层的接口。

    

    然后写一个dao层接口的实现类

 1 public class UserDaoImpl implements UserDao {
 2  
 3 // 需要向dao实现类中注入SqlSessionFactory
 4 // 这里通过构造方法注入
 5 private SqlSessionFactory sqlSessionFactory;
 6  
 7 public UserDaoImpl(SqlSessionFactory sqlSessionFactory) {
 8 this.sqlSessionFactory = sqlSessionFactory;
 9 }
10  
11 @Override
12 public User findUserById(int id) throws Exception {
13 SqlSession sqlSession = sqlSessionFactory.openSession();
14  
15 User user = sqlSession.selectOne("test.findUserById", id);
16  
17 // 释放资源
18 sqlSession.close();
19  
20 return user;
21  
22 }
23  
24 @Override
25 public void insertUser(User user) throws Exception {
26 SqlSession sqlSession = sqlSessionFactory.openSession();
27  
28 //执行插入操作
29 sqlSession.insert("test.insertUser", user);
30  
31 // 提交事务
32 sqlSession.commit();
33  
34 // 释放资源
35 sqlSession.close();
36  
37 }
38  
39 @Override
40 public void deleteUser(int id) throws Exception {
41 SqlSession sqlSession = sqlSessionFactory.openSession();
42  
43 //执行插入操作
44 sqlSession.delete("test.deleteUser", id);
45  
46 // 提交事务
47 sqlSession.commit();
48  
49 // 释放资源
50 sqlSession.close();
51  
52 }
53  
54 }

然后就是对我们写的代码的测试

    这样开发的话有一些问题:

    1.dao接口的实现类中存在大量的重复代码,这些代码会增加程序员的工作量。

    2.在实现类中,SqlSession的方法在调用映射文件中的sql语句时将statement的id(其中的"test.findUserById"便是statment的id)硬编码了。

    

    3.调用SqlSession方法时传入的变量,由于sqlsession方法使用泛型,即使变量类型传入的不是Dao方法中的参数类型,在编译的时候也不会报错,不利于程序的开发。

    

    为了解决这些问题,我们通过满足一些规范就将实体层的实现类的开发省去,由mybatis框架提供的代理实现类替我们去动态的调用我们的映射文件,然后去执行类中的方法。

  mapper代理方法的原理

    这之前,先声明一下,使用mapper代理的时候,命名和之前的不太一样。这里的接口命名由原来的** 改为**Mapper,比如说原来的User接口,现改为UserMapper。其内容和本质没有变,只是换了一个命名规范。除了接口外映射文件也是由User.xml改为UserMapper.xml其内容不变。

    mapper代理方法的思路是,程序员接着写持久层的接口。

    

 

    和对应每个接口的配置文件。

    

   在我们的原来的方法中需要再写一个接口的实现类,用来构建会话工厂(SqlSessionFactory)和对应的会话(SqlSession)然后通过会话去读取映射文件中的sql语句(这里不准确,不过可以这么理解)。那么我么就可以在这个实体类上做点文章了:

    1.我们可以创建一个代理类,在我们相应的接口被调用的时候,代理类就会创建这个对象,创建会话工厂和会话并不难。

    2.还有就是我们的sqlSession对象调用的方法名称,这个很好理解,对应的是我们映射文件的标签。

    3.那么接下来就是传入参数和接收返回值的问题了:

    3.1 传入参数:我们总共需要传入两个参数,一个是映射文件的statement的id的字符串,另外一个是执行需要的参数。 比较困难的是,这个字符串的生成问题。我们的每个方法到底对应的是哪个映射文件的statement的id。对于这个问题,mybatis给出了我们的解决方法:我们的实体层对象读到的字符串是这样的:test.insertUser

    可以将这个id分为两部分,其中的test是我们的映射文件中的namespace的值,这个值让它和持久层接口的地址一致,这样就使得代理对象可以通过接口的地址动态的生成id的前半部分,也就是test的这一部分;而后半部分则是让映射文件中的Statement的id和接口的方法一致。

    也就是说,用户在调用接口的某一个方法的时候,mybatis可以根据接口地址和对应的方法名生成sqlsession对象的方法传入的字符串。这样就解决了传入参数中的字符串的问题了。

    还有就是第二个问题:我们的传入具体参数,mybatis规定,传入参数类型必须和接口的传入参数类型一致。这样,我们的传入参数类型就搞定了。

    3.2传入参数搞定了以后,返回值也就搞定了,跟传入参数的规定一样,返回值的类型要求和接口返回值一致,这样就可以在代理类中将返回值传出了。

    这些搞定了,我们就可以使用代理对象代替我们的实体层具体实现类了。

    至此,这些问题就差不多都解决了,不过还有一个问题:我们的select方法返回值问题,代理对象到底是用selectont方法去查询数据库呢还是使用selectlist方法呢?这个跟我们的接口(mapper)的返回值类型有关——如果mapper方法返回单个pojo对象(非集合对象),代理对象内部通过selectOne查询数据库;如果mapper方法返回集合对象,代理对象内部通过selectList查询数据库。

  mapper代理方法

    原理讲完了,使用其实就基本上没啥要说的了。

    首先我们要创建一个接口。

    

    然后写对应接口的xml文件(截取部分,namespace处就不截图了)。

     

    最后别忘了在SqlMapConfig.xml文件中加载UserMapper.xml。

    

    测试,这里有必要说一下,我们的代理对象是通过SqlSession.getMapper(接口字节码文件)获取的。:

    

    至此,我们的mybatis的实体层的实体层实现类就可以省略不写了。不过这样做的坏处是加强了代码的耦合性,每个接口和每个映射文件必须对应。不过还是感觉通过遵守一定的规范而使得代码量大大减少更爽呢。

posted on 2017-02-10 20:40  精品唯居  阅读(8085)  评论(0编辑  收藏  举报