1. JPA技术选型的思考

在作技术选型的时候是选JPA仍是MyBatis，网上作对比的讨论很是多，双方也是各自有各自的好，谁也不能代替谁。如下是网上讨论的几点概括：

1. JPA更适配OO
2. JPA熟悉后用起来很方便
3. MyBatis灵活性高
4. MyBatis性能更好
5. 国内使用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从技术层面分离。