传统JDBC以及MyBatis和Hibernate的对比

最新推荐文章于 2020-07-20 12:21:37 发布

THE42

最新推荐文章于 2020-07-20 12:21:37 发布

阅读量707

点赞数

分类专栏： -----mybatis 文章标签： hibernate mybatis jdbc

-----mybatis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

首先，让我们回顾一下。在上一个博客中写道“使用传统的JDBC编程来操作数据”，详见http://blog.csdn.net/zwg_html/article/details/55668894

让我们来总结一下使用传统JDBC操作数据需要经过哪几个步骤：

使用JDBC编程需要连接数据库，注册驱动和数据库信息
操作Connection，打开 Statement 对象。
通过Statement执行SQL，返回结果到ResultSet对象。
使用ResultSet读取数据，然后通过代码转化为具体的POJO对象。
关闭数据库的相关资源。

那么，如果我们还是继续使用传统的JDBC方式来操作数据库会存在哪些弊端呢？

工作量相对较大。我们需要先连接，然后处理JDBC底层事务，处理数据类型。我们还需要操作Connection对象、Statement对象和ResultSet对象去拿到数据，并准确的关闭它们
我们要对JDBC编程可能产生的异常进行捕捉处理并正确关闭资源。

对于一个JDBC操作简单的SQL尚且如止的复杂，何况是更为复杂的应用呢？所以这种模式很快的就被一些新的方法所取代了。于是ORM就出现了。不过，我们要知道所有的ORM模型都是基于对JDBC的进行封装，不同的ORM模型对JDBC封闭的强度是不一样的。

那么问题来了。什么是ORM模型。ORM模型的作用是什么。为什么要用ORM模型等一系列疑问。
由于JDBC存在的缺陷，所以我们在实际工作中很少使用JDBC进行操作数据库的编程。于是我们就提出了对象关系映射（Object Relational Mapping）简称 ORM，或者O/RM，或者 O/R mapping。

什么是ORM模型？
　　ORM模型就是数据库的表和简单Java对象（Plain Ordinary Java Object，简称POJO）的映射关系模型。
ORM模型的作用是什么？
　　它主要解决数据库数据和POJO对象的相互映射。我们通过这层映射就可以简单的把数据库表的数据转化为POJO。以便程序员更加容易的理解和应用Java程序.而且程序员一般只需要了解Java应用而无需对数据库进行深入的了解。此外，ORM模型提供了统一的规则使得数据库的数据通过配置便可轻易的映射到POJO上。。

JDBCTemplate

JdbcTemplate针对数据查询提供了多个重载的模板方法,你可以根据需要选用不同的模板方法.如果你的查询很简单，仅仅是传入相应SQL或者相关参数，然后取得一个单一的结果，那么你可以选择如下一组便利的模板方法
优点：运行期：高效、内嵌Spring框架中、支持基于AOP的声明式事务
缺点：①必须于Spring框架结合在一起使用、不支持数据库跨平台、默认没有缓存
②需要手动封装数据（一行一行封装），自定义rowmapper进行封装

目前我们接触到有Hibernate和MyBatis。
　　Hibernate　：本人在大学的时候学的就是这个框架。
　　
　优点：　　

消除了代码的映射规则，它全部被分离到XML或者注解里面去配置。
无需再管理数据库连接，它也配置到XML里面。
一个会话中，不要操作多个对象，只要操作Sesison即可。
关闭资源只需要关闭一个Session即可。

缺点：

全表映射带来的不便，比如更新时需要发送所有的字段。
无法根据不同的条件组装不同的SQL。　
对多表关联和复杂的SQL查询支持较差。需要自己写SQL，返回后，需要自己将数据组装到POJO中。
不能有效支持存储过程。
虽然有HQL，但是性能较差，大型互联网往往需要优化SQL，而Hibernate做不到。

MyBatis：
　是为了解决Hibernate的不足。一个关自动映射的框架MyBatis应运而生。之所以称之为半自动。是国为它需要手动匹配提供POJO、SQL和映射关系。而全表的Hibernate只需要提供POJO和映射关系即可。

优点：

易于上手和掌握。
sql写在xml里，便于统一管理和优化。
解除sql与程序代码的耦合。
提供映射标签，支持对象与数据库的orm字段关系映射
提供对象关系映射标签，支持对象关系组建维护
提供xml标签，支持编写动态sql。

缺点：

sql工作量很大，尤其是字段多、关联表多时，更是如此。
sql依赖于数据库，导致数据库移植性差。
由于xml里标签id必须唯一，导致DAO中方法不支持方法重载。
字段映射标签和对象关系映射标签仅仅是对映射关系的描述，具体实现仍然依赖于sql。（比如配置了一对多Collection标签，如果sql里没有join子表或查询子表的话，查询后返回的对象是不具备对象关系的，即Collection的对象为null）
DAO层过于简单，对象组装的工作量较大。
不支持级联更新、级联删除。
编写动态sql时,不方便调试，尤其逻辑复杂时。
提供的写动态sql的xml标签功能简单（连struts都比不上），编写动态sql仍然受限，且可读性低。
若不查询主键字段，容易造成查询出的对象有“覆盖”现象。
参数的数据类型支持不完善。（如参数为Date类型时，容易报没有get、set方法，需在参数上加@param）
多参数时，使用不方便，功能不够强大。（目前支持的方法有map、对象、注解@param以及默认采用012索引位的方式）
缓存使用不当，容易产生脏数据。

来，让我们了解一下MyBatis的历史。
　历史上，MyBatis的前身是Apache的一个开源项目iBatis。2010年这个项目由apache software foundation 迁移到了google code, 并且改名为MyBatis 。 2013年11 月迁移到GitHub，所以目前的MyBatis是GitHub进行维护的。
　iBatis 一词是源于“Internet”和 “abatis” 的组合，是一个基于Java的持久层框架。iBatis 提供的持久层框架包括SQL Maps和DAO（Data Access Objects）。它能很好的解决Hibernate遇到的问题。与Hibernate不同的是，它不单单要我们提供映射文件，还需要我们提供SQL语句。MyBatis需要提供映射文件包含以下三个部分。

SQL
映射规则
POJO

什么时候用MyBatis（MyBatis 的使用场景）。

　Hibernate作为较为流行的Java ORM框架，它确实编程简易，需要我们提供映射的规则，完全可以通过IDE生成。同时无需编写SQL确实开发效率优于MyBatis。而且，它也提供了缓存、日志、级联、等强大的功能，但是Hibernate的缺陷也是十分的明显的。就是在多表关联复杂的SQL时，数据系统权限限制时，根据条件变化的SQL时。存储过程等使用场景。Hibernate十分不便。而性能又难以通过SQL来优化。所以Hibernate一般只适用于场景不太复杂的、性能要求不太苛刻的时候使用。

　MyBatis 是一个灵活的、可以动态生成映射关系的框架，它几物可以替代JDBC。拥有动态列、动态表名，存储过程都支持。同时提供了简易的缓存（如(默认)一级缓存，还有二级缓存）、日志、级联。但是它的缺陷是需要你提供映射规则和SQL，所以它的开发工作量一般要比Hibernate略大一些。

　　总结。你需要根据你的项目的实际情况去选择框架。MyBatis具有高度灵活、可优化、易维护等特点，所以它目前是大型移动互联网的自选框架。