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從技術層面分離。