在做技术选型的时候是选JPA还是MyBatis，网上做对比的讨论非常多，双方也是各自有各自的好，谁也不能代替谁。以下是网上讨论的几点归纳：
- JPA更适配OO
- JPA熟悉后用起来很方便
- MyBatis灵活性高
- MyBatis性能更好
- 国内使用MyBatis比JPA多
做技术选型时选择的是JPA，我对JPA比较熟，主要针对JPA来谈谈我的想法
引用至【持久层框架JPA与Mybatis该如何选型】
目前java 持久层ORM框架应用最广泛的就是JPA和Mybatis。JPA只是一个ORM框架的规范, 对该规范的实现比较完整就是Spring Data JPA（底层基于Hibernate实现），是基于Spring的数据持久层框架，也就是说它只能用在Spring环境内。Mybatis也是一个优秀的数据持久层框架，能比较好的支持ORM实体关系映射、动态SQL等。
1. JPA设计理念
从设计理念讲，JPA是带有面向对象的思想的，不是简单的CRUD操作。体现在所操作的参数可以是对象，如：
实体对象中包含子对象
@Entity
public class SaleOrder {
private Integer orderId;
private String orderCode;
private Address address;
private List<OrderDetail> orderDetailList;
}
保存可包含子对象
orderRepository.save(saleOrder);
可将主对象和子对象一并操作保存
查询能包含子对象
@Repository
public interface OrderRepository extends JpaRepository<SaleOrder, Integer> {
SaleOrder findByAddress(Address address);
}
- 在对象操作的现象上面体现出设计理念的变化，让开发人员脱离数据库的CRUD，而转向关注领域对象逻辑处理，而领域对象的思考更贴合业务逻辑本身，以结构的开放性保持业务变化的灵活性。
- 实体对象结构的丰富性更体现出客观事物对象结构的丰满性，进一步统一业务与技术的语境，为领域驱动设计提供技术实践支持。
2. Repository仓库接口
- Repository接口的设计更是将业务逻辑设计与存储技术实现分离，让业务逻辑只考虑逻辑设计，存储实现只考虑技术实现
- Repository技术实现上屏蔽了过多的实现细节，表现得非常直接。同时也保留多种存储方式的支持
- 关系型数据库 Mysql SqlServer
- 内存数据库 Redis
- 文档型数据库 MongoDB
- 搜索引擎 Elasticsearch
3. 头痛的查询问题
性能： JPA在使用不当的情况下的确会有一些性能问题，尤其在使用了一对多，多对多关系的情况下，会增加了过多的子查询。我认为少量的子查询在业务处理上是可以接受的并且在性能开销上是可以容忍的。另外为提高性能也可以使用懒加载或部分字段查询的方式，减少过去无用字段和子查询开销。
灵活性： 在不手写SQL的情况下的确失去部分灵活性，尤其是在多表关联查询的情况下，虽然有一些办法可以解决，但终归还是没有MyBatis灵活。在单表查询上JPA还能有较好的表现，而复杂查询可尽量从设计上回避。
4. 架构设计的思考
业务系统尽量回避跨领域对象操作，从需求上回避，从设计上规避，从技术上分离。微服务从顶层设计上切分业务之间的相互作用，领域驱动设计从实现层面对对象进行聚合与分离，CQRS从技术层面分离。
