标签：cto src 不容易 sof sql语句 pojo 框架 快速 服务
一、MyBatis的简介MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架。
MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。
MyBatis可以使用简单的XML或注解用于配置和原始映射，将接口和Java的POJO（Plain Old Java Objects，普通的Java对象）映射成数据库中的记录.
原是apache的一个开源项目iBatis, 2010年6月这个项目由apache software foundation迁移到了google code，随着开发团队转投Google Code旗下，ibatis3.x正式更名为Mybatis ，代码于2013年11月迁移到Github。
iBATIS一词来源于“internet”和“abatis”的组合，是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects(DAO)
(1)、MyBatis是一个工作在持久层的框架,它不再是一个标准的ORM框架
我们先看看Hibernate是如何对数据库进行操作
我们再来看看Mybatis如何对数据库进行操作
因为它只管理了SQL语句和Java之间的关联和映射,生成的实体类将不会自动创建表了,而是我们程序员自己去创建,你这边写的SQL语句是自己写,而不是Hibernate通过save或者delete帮助我们进行创建。
(2)、前身是ibatis, 在ibatis3.x 时，更名为 MyBatis
所以说,在面试或者开发的时候会听到IBatis,MyBatis,其实指的是一个东西。
(3)、MyBatis在java和sql之间提供更灵活的映射方案,MyBatis将sql语句和方法实现，直接写到xml文件中，实现和java程序解耦
为何这样说,MyBatis将接口和SQL映射文件进行分离,相互独立,但又通过反射机制将其进行动态绑定。
其实它底层就是Mapper代理工厂[MapperRegistry]和Mapper标签映射[MapperStatement],它们两个说穿了就是Map容器,就是我们常见的HashMap、ConcurrentHashMap。
在后面我会具体分析MyBatis四大组件的工作原理。
所以说,MyBatis使用面向接口的方式这种思想很好的实现了解耦和的方式,同时易于开发者进行定制和扩展,比如我们熟悉的通用Mapper和分页插件pageHelper,方式也非常简单,后面会详细进行说明。
(4)、 mybatis只负责sql, 建库建表的工作由程序员完成
在使用Hibernate的时候,建表的工作也是由框架帮助我们完成,Hibernate本身就是一个全自动的框架,MyBatis是一个半自动的框架,建表在很多时候我们需要对数据类型和字段进行更信详细的定义和分析,所以说,在实际的生产环境中,MyBatis的这种方式更加符合开发者的习惯
小结:Hibernate相对MyBatis的差异化和区别
(1).Hibernate是一个标准的ORM框架,MyBatis不再是一个标准的ORM框架,它工作在持久层
(2).Hibernate是一个全自动的框架,MyBatis是一个半自动的框架
(3).Hibernate将对数据库的操作全封闭化,MyBatis将其透明化[SQL编写]
(4).MyBatis相对Hibernate来说更加优秀,更加流行
(5).Hibernate是一个重量级的框架,MyBatis相对来说更加轻量级,类似Struts2和SpringMVC
(6).Hibernate的学习成本更高,MyBatis相对来说更低
(7).从耦合度来说,MyBatis实现了最大程度化的解耦,通过面向接口的方式来进行解决
MyBatis很好的借鉴了Hibernate的好的一面,那就是查询后将数据结果集映射的封装工作还是交给我来完成,编写SQL由你自己去完成,处理复杂的自定义结果集映射的权利也交给你来做。
简单的工作封装交给我来做,所以说,这对于Hibernate来说是致命的,因为Hibenate将对表的操作转换为对对象的操作,只需通过操作对象就能帮助我们发送SQL,这是它本身最大的特点优势。
但是,所有的操作都受限于让Hibernate本身来完成,Hibernate最大的优势反而变成了劣势,试想,一位优秀的DBA，对原生的SQL进行了优化,但受限于Hibernate本身的特性,有种浑身无力使的感觉,这也注定Hibernate被MyBatis取代只是时间问题。
MyBatis是一个半自动化的持久化层框架。
jdbc编程—当我们使用jdbc持久化的时候，sql语句被硬编码到java代码中。这样耦合度太高。代码不易于维护。在实际项目开发中会经常添加sql或者修改sql，这样我们就只能到java代码中去修改。
Hibernate和JPA
长难复杂SQL，对于Hibernate而言处理也不容易
内部自动生产的SQL，不容易做特殊优化。
基于全映射的全自动框架，javaBean存在大量字段时无法只映射部分字段。导致数据库性能下降。
对开发人员而言，核心sql还是需要自己优化
sql和java编码分开，功能边界清晰，一个专注业务、一个专注数据。
可以使用简单的XML或注解用于配置和原始映射，将接口和Java的POJO映射成数据库中的记录。成为业务代码+底层数据库的媒介
如果说MyBatis的SQL映射,接口和文件分离这种方式决定了MyBatis的优势,那么MyBatis的动态SQL直接决定了MyBatis它绝对的霸主地位,我们知道后端几乎都是Spring家族的天下,那么它肯定想过使用自家的产品将MyBatis淘汰,它确实做过,但是没有干掉MyBatis,所有MyBatis借助这两大优势和特点,当然MyBatis还有很多优秀的地方,慢慢替代了Hibernate
在一个实际的项目中，sql语句往往是比较复杂的，为了满足更加复杂的业务需求，MyBatis的设计者，提供了动态生成SQL的功能,动态SQL就是根据不同的情况在同一个业务逻辑里面产生的SQL语句是变化的,也就是说根据实际的业务需求同样一段代码产生SQL语句是不一样的,。
在实际的开发中,我们会遇到比较复杂的业务需求,在这种复杂的业务需求中,我们可能需要发送好几个SQL语句才能够去处理的,那么如果我们可以对这个SQL语句进行适当的编程,那么这个SQL语句将会变得非常强大,那么比如说有些数据库是支持存储过程的,这个存储过程其实就是直接使用SQL语句来进行编程,可以根据你不同的情况动态的产生SQL语句
如果我们有相同的业务需求,在这个业务需求中有不同的情况,那我根据不同的情况在同一种请求里面产生的SQL语句也不一样即解决了你要学习存储过程的麻烦,而且存储过程整合起来也很痛苦,同时还解决了可以灵活的适用复杂的业务需求,所以这也是MyBatis优秀的原因,也是它为何能够流行起来
MyBatis它研究了很多地方,让程序更加灵活,它能够设计一个产品,快速的简洁的解决一些需求这才是最好的,这些其实他也能解决,写一个存储过程即可,但是存储过程一些,代码的复杂度又变高了
MyBatis就让你在Mapper里面可以使用if,for循环,多分支语句根据不同的情况产生不同的SQL语句,这就是MyBatis厉害的地方
所以MyBatis在一定程度上就有点把Hibernate就让它有点受不了的地方,因为MyBatis业务需求设计的太好了,这也是目前SSM为何比SSH更流行的原因所以大家一看,好多年解决的问题,设计的问题别人都帮助我们进行了解决,没有理由不用它
哪怕现在流行的分布式和微服务架构,在持久层来说,很大程度上还是使用MyBatis来做持久层,虽然越来越多的项目都是基于SpringBoot,但持久层还是Mybatis用的非常多
MyBatis为何在一定程度上它能够让大家喜欢,用它,就是他让以前的工作变得更加简单容易,而不是变得更难了,如果一样东西变得越来越难,那就没人用它
但是随着技术的发展,将来还会有更好的框架来替代MyBatis,这是肯定的,技术本身就是要不断发展的,如果技术不再发展了,那么我们程序员的价值就会大大降低,因为不需要在学习了,几次互联网的高潮都是由于新技术的产生.导致程序员的薪水大幅度增长
我们通过不同的角度去分析,通过和同期的竞争对手以及在实际的生产环境中,MyBatis都是很优秀的一个持久层框架,我们必须好好学习并掌握它,不光是它的使用,以及它底层的基本原理,这些放在后面会详细介绍,应大家要求,编写MyBatis系列的文章,同时也非常感谢大家的支持!
标签：cto src 不容易 sof sql语句 pojo 框架 快速 服务
原文地址：https://blog.51cto.com/14230003/2364982
