第一课时MyBatis介绍

环境&＃xff1a;

• JDK 1.8
• MySQL 5.7
• Maven 3.6.1
• IDEA

回顾&＃xff1a;

• JDBC
• MySQL
• java基础
• Maven
• Junit

SSM框架&＃xff1a;最好是去官网

什么是Mybatis

• MyBatis 是一款优秀的持久层框架
• MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集的过程
• MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息&＃xff0c;将接口和 Java 的 实体类 【Plain Old Java Objects,普通的 Java对象】映射成数据库中的记录。
• MyBatis 本是apache的一个开源项目ibatis, 2010年这个项目由apache 迁移到了google code&＃xff0c;并且改名为MyBatis 。
• 2013年11月迁移到Github .
• Mybatis官方文档 : http://www.mybatis.org/mybatis-3/zh/index.html
• GitHub : https://github.com/mybatis/mybatis-3

持久化

持久化是将程序数据在持久状态和瞬时状态间转换的机制。

• 即把数据&＃xff08;如内存中的对象&＃xff09;保存到可永久保存的存储设备中&＃xff08;如磁盘&＃xff09;。持久化的主要应用是将内存中的对象存储在数据库中&＃xff0c;或者存储在磁盘文件中、XML数据文件中等等。
• JDBC就是一种持久化机制。文件IO也是一种持久化机制。
• 在生活中 : 将鲜肉冷藏&＃xff0c;吃的时候再解冻的方法也是。将水果做成罐头的方法也是。

为什么需要持久化服务呢&＃xff1f;

那是由于内存本身的缺陷引起的

• 内存&＃xff1a;断电即失断电后数据会丢失&＃xff0c;但有一些对象是无论如何都不能丢失的&＃xff0c;比如银行账号等&＃xff0c;遗憾的是&＃xff0c;人们还无法保证内存永不掉电。
• 内存过于昂贵&＃xff0c;与硬盘、光盘等外存相比&＃xff0c;内存的价格要高2~3个数量级&＃xff0c;而且维持成本也高&＃xff0c;至少需要一直供电吧。所以即使对象不需要永久保存&＃xff0c;也会因为内存的容量限制不能一直呆在内存中&＃xff0c;需要持久化来缓存到外存。

什么是持久层&＃xff1f;

• 完成持久化工作的代码块 . ----> dao层 【DAO (Data Access Object) 数据访问对象】
• 大多数情况下特别是企业级应用&＃xff0c;数据持久化往往也就意味着将内存中的数据保存到磁盘上加以固化&＃xff0c;而持久化的实现过程则大多通过各种关系数据库来完成。
• 不过这里有一个字需要特别强调&＃xff0c;也就是所谓的“层”。对于应用系统而言&＃xff0c;数据持久功能大多是必不可少的组成部分。也就是说&＃xff0c;我们的系统中&＃xff0c;已经天然的具备了“持久层”概念&＃xff1f;也许是&＃xff0c;但也许实际情况并非如此。之所以要独立出一个“持久层”的概念,而不是“持久模块”&＃xff0c;“持久单元”&＃xff0c;也就意味着&＃xff0c;我们的系统架构中&＃xff0c;应该有一个相对独立的逻辑层面&＃xff0c;专注于数据持久化逻辑的实现.
• 与系统其他部分相对而言&＃xff0c;这个层面应该具有一个较为清晰和严格的逻辑边界。【说白了就是用来操作数据库存在的&＃xff01;】

为什么需要Mybatis

• Mybatis就是帮助程序猿将数据存入数据库中 , 和从数据库中取数据 .

• 传统的jdbc操作 , 有很多重复代码块 .比如 : 数据取出时的封装 , 数据库的建立连接等等… , 通过框架可以减少重复代码,提高开发效率 .

• MyBatis 是一个半自动化的ORM框架 (Object Relationship Mapping) -->对象关系映射

• 所有的事情&＃xff0c;不用Mybatis依旧可以做到&＃xff0c;只是用了它&＃xff0c;所有实现会更加简单&＃xff01;技术没有高低之分&＃xff0c;只有使用这个技术的人有高低之别

• MyBatis的优点

• • 简单易学&＃xff1a;本身就很小且简单。没有任何第三方依赖&＃xff0c;最简单安装只要两个jar文件&＃43;配置几个sql映射文件就可以了&＃xff0c;易于学习&＃xff0c;易于使用&＃xff0c;通过文档和源代码&＃xff0c;可以比较完全的掌握它的设计思路和实现。
  • 灵活&＃xff1a;mybatis不会对应用程序或者数据库的现有设计强加任何影响。sql写在xml里&＃xff0c;便于统一管理和优化。通过sql语句可以满足操作数据库的所有需求。
  • 解除sql与程序代码的耦合&＃xff1a;通过提供DAO层&＃xff0c;将业务逻辑和数据访问逻辑分离&＃xff0c;使系统的设计更清晰&＃xff0c;更易维护&＃xff0c;更易单元测试。sql和代码的分离&＃xff0c;提高了可维护性。
  • 提供xml标签&＃xff0c;支持编写动态sql。

• 最重要的一点&＃xff0c;使用的人多&＃xff01;公司需要&＃xff01;

SqlSessionFactoryBuilder

这个类可以被实例化、使用和丢弃&＃xff0c;一旦创建了 SqlSessionFactory&＃xff0c;就不再需要它了。 因此 SqlSessionFactoryBuilder 实例的最佳作用域是方法作用域&＃xff08;也就是局部方法变量&＃xff09;。 你可以重用 SqlSessionFactoryBuilder 来创建多个 SqlSessionFactory 实例&＃xff0c;但最好还是不要一直保留着它&＃xff0c;以保证所有的 XML 解析资源可以被释放给更重要的事情。

SqlSessionFactory

SqlSessionFactory 一旦被创建就应该在应用的运行期间一直存在&＃xff0c;没有任何理由丢弃它或重新创建另一个实例。 使用 SqlSessionFactory 的最佳实践是在应用运行期间不要重复创建多次&＃xff0c;多次重建 SqlSessionFactory 被视为一种代码“坏习惯”。因此 SqlSessionFactory 的最佳作用域是应用作用域。 有很多方法可以做到&＃xff0c;最简单的就是使用单例模式或者静态单例模式。

SqlSession

每个线程都应该有它自己的 SqlSession 实例。SqlSession 的实例不是线程安全的&＃xff0c;因此是不能被共享的&＃xff0c;所以它的最佳的作用域是请求或方法作用域。 绝对不能将 SqlSession 实例的引用放在一个类的静态域&＃xff0c;甚至一个类的实例变量也不行。 也绝不能将 SqlSession 实例的引用放在任何类型的托管作用域中&＃xff0c;比如 Servlet 框架中的 HttpSession。 如果你现在正在使用一种 Web 框架&＃xff0c;考虑将 SqlSession 放在一个和 HTTP 请求相似的作用域中。 换句话说&＃xff0c;每次收到 HTTP 请求&＃xff0c;就可以打开一个 SqlSession&＃xff0c;返回一个响应后&＃xff0c;就关闭它。 这个关闭操作很重要&＃xff0c;为了确保每次都能执行关闭操作&＃xff0c;你应该把这个关闭操作放到 finally 块中。 下面的示例就是一个确保 SqlSession 关闭的标准模式&＃xff1a;

try (SqlSession session &＃61; sqlSessionFactory.openSession()) {// 你的应用逻辑代码
}


在所有代码中都遵循这种使用模式&＃xff0c;可以保证所有数据库资源都能被正确地关闭。

映射器实例

映射器是一些绑定映射语句的接口。映射器接口的实例是从 SqlSession 中获得的。虽然从技术层面上来讲&＃xff0c;任何映射器实例的最大作用域与请求它们的 SqlSession 相同。但方法作用域才是映射器实例的最合适的作用域。 也就是说&＃xff0c;映射器实例应该在调用它们的方法中被获取&＃xff0c;使用完毕之后即可丢弃。 映射器实例并不需要被显式地关闭。尽管在整个请求作用域保留映射器实例不会有什么问题&＃xff0c;但是你很快会发现&＃xff0c;在这个作用域上管理太多像 SqlSession 的资源会让你忙不过来。 因此&＃xff0c;最好将映射器放在方法作用域内。就像下面的例子一样&＃xff1a;

try (SqlSession session &＃61; sqlSessionFactory.openSession()) {BlogMapper mapper &＃61; session.getMapper(BlogMapper.class);// 你的应用逻辑代码
}