MyBatis学习06-各ORM框架对比

1 JDBC

非 ORM 框架，JAVA 最低层的数据库操作方式。

1.1 使用场景

现在已经很少使用 JDBC 进行数据库的操作了。使用的场景有：

1. 一些对数据库相关性能有极致要求的小系统。
2. 培训或者教学使用。

1.2 优点

• 所有 ORM 框架底层最终都会使用到 JDBC 方式，JDBC 方式是所有 ORM 框架的基石。掌握 JDBC 有助于学习后续所有的 ORM 框架。
• 性能是最快的。
• 兼容所有的数据库（只要有对应的数据库驱动包）。

1.3 缺点

• 封闭程度不够，需要开发写的代码比较多。
• 数据库连接、预加载、结果集等资源需要开发单独进行管理。
• SQL 存在硬编码。
• 结果集进行对象映射还需要单独进行抽取才能适应不同的对象。

2 DbUtils

非 ORM 框架，对 JDBC 进行了简单的封装。

2.1 使用场景

由于各 ORM 框架的兴起，DbUtils 现在基本很少使用，使用场景有：

1. 一些不想集成 Spring框架、不想集成 ORM 框架只想简单进行实现的小系统。
2. 先前一些小公司自己使用 DbUtils 封装好的框架，基于成本考虑不想升级框架，由这类框架开发的系统。

2.2 优点

• 对 JDBC 进行了基础的封闭，开发过程更方便。
• 加强了对资源的管理，如只要传入数据源，后续使用过程中都是主动进行数据源的关闭。
• 加载了对结果集的操作，只要传入对应的 model 类，就可以自动将结果集映射成对象数据。
• 解决了可能由于研发人员疏忽导致连接池或其它对象未关闭的问题。

2.3 缺点

• 封闭程度不够，还是需要开发进行功能的补充，如获取数据源。
• SQL 存在硬编码。
• 连接池等管理上存在问题，如调用查询等接口后，DbUtils会主动关闭数据库连接，该操作对性能会有影响。
• 该技术比较旧，官网上2017年7月后就没有再更新了。

3 JdbcTemplate

非 ORM 框架，对 JDBC 进行了简单的封装。

3.1 使用场景

JdbcTemplate 是 Spring 对 JDBC 的一层封装，使用 JdbcTemplate 必须要集成 Spring，但 Spring 同时提供了 Spring Data JPA，使用 JdbcTemplate 不如使用 Spring Data JPA，不集成 Spring 则可以使用 Mybatis、Hibernate 等其它的 ORM 框架，由于笔者接触的项目不多，想不到 JdbcTemplate 的使用场景。个人猜测，使用场景如下：

1. 集成了 Spring ，项目规模不大，只需要基础的 JdbcTemplate 功能实现即可实现功能。
2. 对项目的性能、设计规划无太多的要求，只需要简单的实现的系统。

3.2 优点

• 是 Spring 对 JDBC 的一层封装，可灵活的进行 Sql 语句的编写。
• 性能基本上与纯 JDBC 方式一致。
• 基于 Spring，目前大部分系统都会集成 Spring 进行开发，所以可以天然的使用 JdbcTemplate。
• 与 Spring 配合使用，数据源、数据库连接池等其它资源都交由 Spring 进行管理

3.3 缺点

• 只是 Spring 进行了封装，封装程度不够高，开发过程中还是需要写大量的代码。
• SQL 存在硬编码。
• 要使用时必须基于 Spring 框架进行使用。
• 在代码中存在硬编码。

4 Hibernate

重量级的 ORM 框架。

4.1 使用场景

1. 由于框架是重量级的，所以 Hibernate 适配在大规模的系统中使用。
2. 对 SQL 优化要求不高的系统。
3. 系统间表关系较简单。
4. 对研发效率有一定要求。

4.2 优点

• 对象化。人员以面相对象的思想来操作数据库。Hibernate 支持许多面向对象的特性，如组合，继承，多态等。
• 更好的移植性.对于不同的数据库，开发者只需要使用相同的数据操作即可.
• 开发效率高。Hibernate 提供了大量的封装（这也是它最大的缺点），很多数据操作以及关联关系等都被封装的很好，开发者不需写大量的sql语句，这就极大的提高了开发者的开发效率。
• 缓存机制的使用。Hibernate （session 缓存，二级缓存，查询缓存），对于那些改动不大且经常使用的数据，可以将它们放到缓存中，不必在每次使用时都去查询数据库，缓存机制对提升性能大有裨益。

4.3 缺点

• 由于对持久层封装过于完整，导致开发人员无法对 SQL 进行优化，无法灵活使用 JDBC 的原生 SQL，Hibernate 封装了 JDBC，所以没有 JDBC 直接访问数据库效率高。要使用数据库的特定优化机制的时候，不适合用 Hibernate。
• 框架中使用 ORM 原则，导致配置过于复杂，一旦遇到大型项目，比如300张表以上，配置文件和内容是非常庞大的，另外，DTO 满天飞，性能和维护问题随之而来
• 如果项目中各个表中关系复杂，表之间的关系很多，在很多地方把 lazy 都设置 false，会导致数据查询和加载很慢，尤其是级联查询的时候。
• Hibernate 在批量数据处理时有弱势，对于批量的修改，删除，不适合用 Hibernate,这也是 ORM 框架的弱点。Hibernate 不适用于小型项目。
• 针对单一对象简单的增删查改，适合于 Hibernate,而对于批量的修改，删除，不适合用 Hibernate,这也是 ORM 框架的弱点；要使用数据库的特定优化机制的时候，不适合用 Hibernate。

5 Spring-Data-JPA

ORM 框架。

5.1 使用场景

1. 对系统性能没有极致的要求。
2. 关注开发效率、开发成本。
3. 系统逻辑较简单，没有很多的复杂的SQL。

5.2 优点

• Spring 对 DAO 的高度封装，不需要编写SQL就可以完成大部分业务的数据库操作。
• 内置了基础的数据库操作接口，开发过程中只需要实现定制化的接口即可，大量减少开发的工作量。
• 数据库移植性高。
• 基于 Spring， 目前大部分份系统都会集成 Spring 进行开发，集成方便。
• 使用简单，系统开发成本最低，开发效率完胜其它所有的 ORM 框架。

5.3 缺点

• 对于复杂 sql 编写存在硬编码，且会导致系统风格不统一问题。
• jPA 在性能优化是个问题。

6 Mybatis

半 ORM 框架。

6.1 使用场景

1. 对系统数据库方面性能要求高。
2. 系统复杂，预估后期经常存在进行数据库 SQL 性能优化的系统。
3. 数据库设计中，数据库存在一些大字段，开发过程需要按需查询大字段的场景（Hibernate 或者 Spring Data JPA 会把整个数据库所有字段都查询出来，所以不太适合）。

6.2 优点

• 轻量级的半 ORM 框架，对 JDBC 进行了一定的封装，简单易学。
• SQL 语句单独写在 XML 文件中，不存在这块的硬编码
• 由于 SQL 文件的单独规划，对于系统的 SQL 的性能优化非常的方便。

6.3 缺点

• 所有的 SQL 都需要研发人员进行编写，开发效率比其它的 ORM 框架要低很多。
• 由于 SQL 全是研发人员进行编写的，对于数据库的兼容性比较差，如果一套系统需要同时兼容多款数据库，则需要研发人员同时编写多个不同的数据库对应的语句。
• Mybatis 中的一级缓存与二级缓存，对于现在常规的系统设计（设计上都是使用 redis 等第三方缓存数据库，且缓存方式需要按系统业务规则进行设计，Mybatis 自带的缓存无法应用于各个不同的系统）中有点鸡肋。