|
|---|
|
|
|
|
|
|
w********m
发帖数: 1137 | 1 现在Dao持久层的解决方案中，大部分是采用Spring Data JPA或MyBatis解决方案，并
且传统企业多用前者，互联网企业多用后者。Spring Data JPA 是Spring Data 在JPA
（Java持久层规范）和ORM（对象关系映射）框架之间抽象封装层，它不直接代替ORM框
架，默认低层使用的ORM框架是Hibernate，但使用它可以灵活的在各种ORM框架之间切
换，并且减少ORM框架接入部分重复代码，进而简化代码。MyBatis是一个持久层框架的
，但它设计初衷与Hibernate等全自动、符合JPA规范的ORM框架不同，重点关注关系到
对象的（R——》O），而后者不仅是关系到对象的映射，还有对象到关系的映射（O—
—》R），
设计上希望通过面向对象的方式写SQL，可以更好的屏蔽不同数据库之间的差异，抽象
程度更高。而前者MyBatis需要自己手动写SQL，更灵活，但受限于开发编写SQL代码水
平，可能会出现不兼容不同数据库SQL的情况。网上也有观点认为ORM是一种反模式，认
为从关系数据库到面向对象不完全是一一对应的，强行的要ORM反而会让一些设计变得
很奇怪。总的来说，Spring Data JPA和MyBatis都是很不错且被广泛使用的持久层解决
方案，具体用那个可以看团队成员对技术栈熟悉程度以及项目是否对数据持久层方面有
特殊需求。相对来说Spring Data JPA/Hibernate用好的话会简单些，不过复杂查询及
结果集的返回没有直接用MyBatis灵活方便，可参考如下解决方案：
使用Spring Data JPA + QueryDSL + Hibernate。 基本的增删改查和调用存储过程通
过Spring Data JPA Repository来解决 稍微复杂的查询或是批量操作使用QueryDSL或
Spring Data Specification的API来解决 特别特别复杂的查询操作可以使用Spring
Data JPA Repository的注解定义native sql来解决 所有持久层底层操作都由
Hibernate来支持，且为了保证效率和性能，不需要的包/特性就不需要引入，基本上使
用core包就能够解决问题，当然如果有需要可以加上orm 全过程脱离任何格式(.java除
外)的配置文件，都使用Java Config的方式进行配置，除了需要抽象出一套自己架构的
持久层的API以外，只需要提供一个独立的空内容.java配置文件(如果不需要多数据源
配置的话)，在类上面配置RepositoryFactoryBean和Repository接口包路径全使用过程
中，除了native sql处以外，全部持久层操作都是类型安全的，特别是使用QueryDSL或
Specification后... 从此，mybatis根本就没有存在的必要... | T*******x
发帖数: 8565 | 2 这是十年前的文章文章吗？
JPA
【在 w********m 的大作中提到】
: 现在Dao持久层的解决方案中，大部分是采用Spring Data JPA或MyBatis解决方案，并
: 且传统企业多用前者，互联网企业多用后者。Spring Data JPA 是Spring Data 在JPA
: （Java持久层规范）和ORM（对象关系映射）框架之间抽象封装层，它不直接代替ORM框
: 架，默认低层使用的ORM框架是Hibernate，但使用它可以灵活的在各种ORM框架之间切
: 换，并且减少ORM框架接入部分重复代码，进而简化代码。MyBatis是一个持久层框架的
: ，但它设计初衷与Hibernate等全自动、符合JPA规范的ORM框架不同，重点关注关系到
: 对象的（R——》O），而后者不仅是关系到对象的映射，还有对象到关系的映射（O—
: —》R），
: 设计上希望通过面向对象的方式写SQL，可以更好的屏蔽不同数据库之间的差异，抽象
: 程度更高。而前者MyBatis需要自己手动写SQL，更灵活，但受限于开发编写SQL代码水
|
|
|
|
|
|
|
