[由零开始] 二、手写Mybatis-自定义持久层框架思路分析

自定义持久层框架思路分析

自定义持久层框架 本质上就是对JDBC的代码封装
在封装的时候解决或规避我们上一章分析出的问题

自定义持久层框架设计分析

首先我们想要自定义框架供使用者使用 我们思考的问题就是要从使用者的角度出发

使用者(项目): 引入我们自定义的持久层框架的jar包(目的是利用框架对数据库进行操作)
   使用者需要提供两部分信息 1、数据库配置信息 2、sql配置信息(包括sql 、出入参)
      (1)自定义文件存放数据库配置信息(sqlMapConfig.xml)
      (2)自定义文件存放sql信息(mapper.xml)

自定义框架本身(完整工程): 本质上就是对JDBC代码进行封装
      (1) 加载配置文件 : 根据配置文件的路径, 加载配置文件成字节输入流, 存储在内存中
      (2) 创建两个javaBean (容器对象) :存放配置文件解析出来的内容
      (3) 利用dom4j 解析配置文件
      (4) 写相关代码执行JDBC代码

自定义持久层框架实现

使用者端

使用者端就是我们自定义框架的使用者
原则上框架的引用是为了简化使用者的开发流程
所以使用端要做的就相对简单一点
只需要将写好数据库的配置文件和相应的sql配置信息 传递给框架就好
记得引用自定义框架的jar包

<configuration>
    <!--数据库配置信息-->
    <dataSource>
        <property name="driverClass"  value="com.mysql.jdbc.Driver"></property>
        <property name="jdbcUrl"  value="jdbc:mysql:///mrsoon"></property>
        <property name="username"  value="root"></property>
        <property name="password"  value="root"></property>
    </dataSource>
<!--存放mapper.xml路径-->
    <mapper resoirces="userMapper.xml"></mapper>
</configuration>

这个数据库配置文件 我们自定义名称为sqlMapConfig.xml 之所以这么起名就是为了更好的理解Mybatis 后续看Mybatis的源码也更容易理解 当然叫什么名字都可以
把mapper路径存放在sqlMapConfig.xml里是因为只要解析一次就可以知道mapper的全部路径不需要二次传递
xml的标签名称也都是可以自己定义的 一切起名都是为了适应Mybatis的源码规范
毕竟我们最终的目的是为了完全的写出Mybatis

<mapper namespace="user">


    <!--sql的唯一标识 ： namespace.id来组成 ：  statementId-->
    <select id="selectList"  resultType="com.mrsoon.pojo.User">
        select * from user
    </select>


    <select id="selectOne" resultType="com.mrsoon.pojo.User"  paramterType="com.mrsoon.pojo.User">
        select * from user where id = #{id} and username = #{username}
    </select>

</mapper>

这是mapper的信息 我们在解析sql的时候需要特定的名称 所以statementId就出现了 这个名称也是自己定义的 规则是namespace.id来组成 当然也可以用其他

自定义框架端

自定义框架端比较繁琐 涉及东西比较多
使用dom4j 解析配置文件
c3p0连接池等等
最主要的还是其中思想
实际上我们开发之时以一条功能线为主线的去开发还是很好理解的
毕竟通往罗马的路不止一条
我自己本人是不喜欢看太长的博客…
下一期我们将一起完成自定义框架端的写法