【SSM 3】Mybatis应用,和Hibernate的区别

PS:每次写概念性的总结,都是各种复制,各种粘,然后各种理解各种猜。但是这一步的总结,决定了我能够再这条路上走的远近和是否开心、是否创造!so,开启Ctrl A+Ctrl C的模式吧。

接触到这个概念的时候,很熟悉的感觉又回来了。想起了那时候研究.NET的Entity Framework的时候,那时候,是我第一次接触到Hibernate和Mybatis,iBatis等等。因为当时将ORM框架的实现,分为了.NET和Java体系。我说过,我会回来的,将近一年,我终于能够去用上这个传说中的Mybatis了!

在说Mybatis之前,先看看什么是ORM框架吧,博客:【EF 4】ORM框架及其流行产品之一EF介绍

一、Mybatis概述

MyBatis:是一个支持普通SQL查询,存储过程和高级映射的优秀持久层框架。MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。MyBatis可以使用简单的XML或注解用于配置和原始映射,将接口和Java的POJO(Plain Old Java Objects,普通的Java对象)映射成数据库中的记录。

那么根据ORM框架,O就是我们常说的实体对象了,R就是关系映射,M就是mapper(我理解为地图索引)。先看一下Mybatis的简单应用体系:

【SSM 3】Mybatis应用,和Hibernate的区别

Mybatis主要需要两个文件(结合图片实例),一个是实体文件TbUser,一个是TbuserMapper.xml。就跟EF框架中所生成的 edmx文件一样,mapper.xml描述了实体和数据库之间的映射关系。而且,Mybatis是一个半自动的框架,它的sql语句,也写在这个xml文件里。

PS:说到这里,真的忍不住再说说EF,我猜很多人都不知道EF的edmx这个文件是可以写存储过程和函数的。其实,那个edmx的作用,就可以简单等于Mybatis的mapper.xml的作用。简单点说,看过EF三大工作模式,再来看这个Mybatis,别的深入的不敢说,但要是单纯的应用,绝对是没有问题的!

PS:关于Mybatis的mapper配置,下一篇博客详细介绍

二、和Hibernate的区别

首先,了解一下hibernate,系列博客: SSH   里面写了hibernate的用处,hibernate的映射关系、缓存、抓取策略等等。

其次,区别(纯手工个人总结)

说这个区别前,我最大的一个感受就是,Hibernate和Mybatis,如果对应到EF的话,纯粹就是把那三个工作模式给每一个都自立门户整了一个框架。(一家之谈,只对应奴家的知识网络图)

1,开发速度

Hibernate可以算是全自动的,它和EF一样,本身便封装了很多的方法供给开发人员使用

Mybatis是半自动的(我想说纯手工制作,但都不太合适),它本身并没有为开发人员提供过多的方法,在开发的时候,需要手写SQL语句。

所以,从开发速度上来说,Hibernate可能更胜一筹。PS:Mybatis有其自身的逆向工程生成工具,那时候,这速度的对比,还不一定!

2,缓存和抓取

这个不用说,Hibernate完胜。hibernate支持一级缓存、二级缓存等等等等,它的抓取策略也是性能调优的好方法。不多说了,系列博客: SSH

3,Mybatis的特别

1,执行效率高:它的开发速度慢,并不意味着它的执行速度也慢。不管是Hibernate,还是EF,我们知道,最终要去数据库获取数据,都是对应的SQL语句(相应的查询语句)Mybatis,它直接执行的就是SQL原生语句,而hibernate经过封装使用hql,不管它转化的效率有多高,总是废了时间的!

2,灵活:开发速度慢,是因为没有封装好的方法,每个方法都要自己手写SQL语句,可是,这也就是意味着,你可以利用SQL语句写各种增删改语句。这点对于互联网产品,需求变化比较快的产品来说,Mybatis完胜。ps:spring提供了spring data jpa可以跟hibernate结合解决查询灵活性的问题,但是相对来说,哪有直接整原生SQL来的猛呢!

3,资源利用率高:说实在的,这一点的感悟是基于,我目前觉得,能够真正用好一款产品的人,非常好。Hibernate确实是封装了很多东西,但是,并不是每个人都知道它究竟提供了哪些资源,也就是说,Hibernate所提供的资源,很多被浪费!而Mybatis,基本上是写一个就能用上一个(不用的话,你老人家写着SQL语句玩耍吗?)

三、总结

好饿,不写了,以后有时间了再说吧,最近对于各种框架的应用有很大的感触。其实Hibernate和Mybatis各有优劣吧。如果系统需求比较稳定,那选hibernate没什么不好。底层方法基本上都有了。如果系统需求比较灵活,常常涉及到多表操作,那就整Mybatis吧,想怎么写就怎么写。如果又不想开发基本的单表操作方法,不想放弃hibernate的抓取和缓存。那就两个一起使吧,也没什么不好!(我们目前的系统,就是Hibernate和Mybatis两个一起使)

但是,我想说的是,如果将Mybatis基本的增删改等操作进行抽象封装成公共的mapper,然后通过传入的实体,判断操作具体的数据库表单,好像也是可以的。至少这时候,我就不太乐意再去捯饬一个hibernate进入系统了。缓存什么的,或许可以引入专门解决缓存 的工具,如radis、memchache等啊。

真不说了,好饿。下一篇博客接着写!刚刚写博客的过程中,我又回去把我那个EF的研究资料瞅了几眼,好开森!

上一篇:基于Docker搭建大数据集群(五)Mlsql部署


下一篇:题目1437:To Fill or Not to Fill:贪心算法解决加油站选择问题(未解决)