[由零开始] 二、手写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连接池等等
最主要的还是其中思想
实际上我们开发之时以一条功能线为主线的去开发还是很好理解的
毕竟通往罗马的路不止一条
我自己本人是不喜欢看太长的博客…
下一期我们将一起完成自定义框架端的写法