Spring Data JPA系列3：JPA專案中核心場景與進階用法介紹

架構悟道發表於2022-06-24
Spring

大家好，又見面了。

到這裡呢，已經是本SpringData JPA系列文件的第三篇了，先來回顧下前面兩篇：

本篇內容將在上一篇已有的內容基礎上，進一步的聊一下專案中使用JPA的一些高階複雜場景的實踐指導，覆蓋了主要核心的JPA使用場景，可以讓你在需求開發的時候對JPA的使用更加的遊刃有餘。

Repository

上一篇文件中，我們知道業務程式碼中直接呼叫Repository層中預設提供的方法或者是自己自定義的介面方法，便可以進行DB的相關操作。這裡我們再對repository的整體實現情況進一步探索下。

repository全貌梳理

先看下Repository相關的類圖：

整體類圖雖然咋看上去很龐雜，但其實主線脈絡還是比較清晰的。

  • 先看下藍色的部分其實就是Repository的一整個介面定義鏈條，而橙色的則是我們自己自定義的一些Repository介面類，繼承父層介面的所有已有能力。
  • 左側的類圖與介面，其實都是JPA提供的一些用於實現或者定製查詢操作的一些輔助實現類，後面章節中會看到他們的身影。

對主體repository層級提供的主要方法進行簡單的梳理，如下：

下面對各個repository介面進行簡單的獨立介紹。

JpaRepository與它的父類們

  • Repository位於Spring Data Common的lib裡面，是Spring Data 裡面做資料庫操作的最底層的抽象介面、最頂級的父類，原始碼裡面其實什麼方法都沒有，僅僅起到一個標識作用。
  • CrudRepository作為直接繼承Repository的次頂層介面類，看名字也可以大致猜測出其主要作用就是封裝提供基礎CRUD操作。
  • PagingAndSortingRepository繼承自CrudRepository，自然也就具備了CrudRepository提供的全部介面能力。此外，從其自身新提供的介面來看，增加了排序和分頁查詢列表的能力，非常符合其類名的含義。

JpaRepository與其前面的幾個父類相比是個特殊的存在，其中補充新增了一組JPA規範的介面方法。前面的幾個介面類都是Spring Data為了相容NoSQL而進行的一些抽象封裝（因為SpringData專案是一個龐大的家族，支援各種SQL與NoSQL的資料庫，SpringData JPA是SpringData家族中面向SQL資料庫的一個子分支專案），從JpaRepository開始是對關係型資料庫進行抽象封裝。

從類圖可以看得出來它繼承了PagingAndSortingRepository類，也就繼承了其所有方法，並且實現類也是SimpleJpaRepository。從類圖上還可以看出JpaRepository繼承和擁有了QueryByExampleExecutor的相關方法。

通過原始碼和CrudRepository相比較，它支援Query By Example，批量刪除，提高刪除效率，手動重新整理資料庫的更改方法，並將預設實現的查詢結果變成了List。

額外補充一句：

實際的專案編碼中，大部分的場景中，我們自定義Repository都是繼承JpaRepository來實現的。

自定義Repository

先看個自定義Repository的例子，如下：

看下對應類圖結構，自定義Repository繼承了JpaRepository，具備了其父系所有的操作介面，此外，額外擴充套件了業務層面自定義的一些介面方法：

自定義Repository的時候，繼承JpaRepository需要傳入兩個泛型：

  • 此Repository需要操作的具體Entity物件（Entity與具體DB中表對映，所以指定Entity也等同於指定了此Repository所對應的目標操作Table），
  • 此Entity實體的主鍵資料型別（也就是第一個引數指定的Entity類中以@Id註解標識的欄位的型別）

分頁、排序，一招搞定

分頁，排序使用Pageable物件進行傳遞，其中包含Page和Sort引數物件。

查詢的時候，直接傳遞Pageable引數即可（注意下，如果是用原生SQL查詢的方式，此法行不通，後文有詳細說明）。


// 定義repository介面的時候，直接傳入Pageable引數即可
List<UserEntity> findAllByDepartment(DepartmentEntity department, Pageable pageable);

還有一種特殊的分頁場景。比如，DB表中有100w條記錄，然後現在需要將這些資料全量的載入到ES中。如果逐條查詢然後插入ES，顯然效率太慢；如果一次性全部查詢出來然後直接往ES寫，服務端記憶體可能會爆掉。

這種場景，其實可以基於Slice結果物件進行實現。Slice的作用是，只知道是否有下一個Slice可用，不會執行count，所以當查詢較大的結果集時，只知道資料是足夠的就可以了，而且相關的業務場景也不用關心一共有多少頁。


private <T extends EsDocument, F> void fullLoadToEs(IESLoadService<T, F> esLoadService) {
    try {
        final int batchHandleSize = 10000;
        Pageable pageable = PageRequest.of(0, batchHandleSize);
        do {
            // 批量載入資料，返回Slice型別結果
            Slice<F> entitySilce = esLoadService.slicePageQueryData(pageable);

            // 具體業務處理邏輯
            List<T> esDocumentData = esLoadService.buildEsDocumentData(entitySilce);
            esUtil.batchSaveOrUpdateAsync(esDocumentData);

            // 獲取本次實際上載入到的具體資料量
            int pageLoadedCount = entitySilce.getNumberOfElements();
            if (!entitySilce.hasNext()) {
                break;
            }

            // 自動重置page分頁引數，繼續拉取下一批資料
            pageable = entitySilce.nextPageable();
        } while (true);
    } catch (Exception e) {
        log.error("error occurred when load data into es", e);
    }
}

複雜搜尋，其實不復雜

按照條件進行搜尋查詢，是專案中遇到的非常典型且常用的場景。但是條件搜尋也分幾種場景，下面分開說下。

簡單固定場景

所謂簡單固定，即查詢條件就是固定的1個欄位或者若干個欄位，且查詢欄位數量不會變，比如根據部門查詢具體人員列表這種。
這種情況，我們可以簡單的直接在repository中，根據命名規範定義一個介面即可。


@Repository
public interface UserRepository extends JpaRepository<UserEntity, Long> {
    // 根據一個固定欄位查詢
    List<UserEntity> findAllByDepartment(DepartmentEntity department);
    // 根據多個固定欄位組合查詢
    UserEntity findFirstByWorkIdAndUserNameAndDepartment(String workId, String userName, DepartmentEntity department);
}

簡單不固定場景

考慮一種場景，介面上需要做一個使用者搜尋的能力，要求支援根據使用者名稱、工號、部門、性別、年齡、職務等等若干個欄位中的1個或者多個的組合來查詢符合條件的使用者資訊。
顯然，上述通過直接在repository中按照命名規則定義介面的方式行不通了。這個時候，Example物件便排上用場了。

其實在前面整體介紹Repository的UML圖中，就已經有了Example的身影了，雖然這個名字起的很敷衍，但其功能確是挺實在的。

看下具體用法：


public Page<UserEntity> queryUsers(Request request, UserEntity queryParams) {
    // 查詢條件構造出對應Entity物件，轉為Example查詢條件
    Example<UserEntity> example = Example.of(queryParams);
    // 構造分頁引數
    Pageable pageable = PageHelper.buildPageable(request);
    
    // 按照條件查詢，並分頁返回結果
    return userRepository.findAll(example, pageable);
}

複雜場景

如果是一些自定義的複雜查詢場景，可以通過定製SQL語句的方式來實現。


@Repository
public interface UserRepository extends JpaRepository<UserEntity, Long> {
    @Query(
        value = "select t.*,(select group_concat(a.assigner_name) from workflow_task a where a.state='R' and a.proc_inst_id=t.proc_inst_id) deal_person,"
            + " (select a.task_name from workflow_task a where a.state='R' and a.proc_inst_id=t.proc_inst_id limit 1) cur_step "
            + "   from workflow_info t where t.state='R'  and t.type in (?1) "
            + "and exists(select 1 from workflow_task b where b.assigner=?2 and b.state='R' and b.proc_inst_id=t.proc_inst_id) order by t.create_time desc",
        countQuery = "select count(1) from workflow_info t where t.state='R'  and t.type in (?1) "
            + "and exists(select 1 from workflow_task b where b.assigner=?2 and b.state='R' and b.proc_inst_id=t.proc_inst_id) ",
        nativeQuery = true)
    Page<FlowResource> queryResource(List<String> type, String workId, Pageable pageable);
}

此外，還可以基於JpaSpecificationExecutor提供的能力介面來實現。
自定義介面需要增加JpaSpecificationExecutor的繼承，然後利用Page<T> findAll(@Nullable Specification<T> spec, Pageable pageable);介面來實現複雜查詢能力。


// 增加對JpaSpecificationExecutor的繼承
@Repository
public interface UserRepository extends JpaRepository<UserEntity, Long>, JpaSpecificationExecutor<UserEntity> {

}



public List<UserEntity> queryUsers(QueryParams queryParams) {
    // 構造Specification查詢條件
    Specification<UserEntity> specification =
        (root, query, cb) -> {
            List<Predicate> predicates = new ArrayList<>();
            // 範圍查詢條件構造
            predicates.add(cb.greaterThanOrEqualTo(root.get("age"), queryParams.getMinAge()));
            predicates.add(cb.lessThanOrEqualTo(root.get("age"), queryParams.getMaxAge()));
            // 精確匹配查詢條件構造
            predicates.add(cb.equal(root.get("department"), queryParams.getDepartment()));
            // 關鍵字模糊匹配條件構造
            if (Objects.nonNull(queryParams.getNameKeyword())) {
                predicates.add(cb.like(root.get("userName"), "%" + queryParams.getNameKeyword() + "%"));
            }
            return query.where(predicates.toArray(new Predicate[0])).getRestriction();
        };
    // 執行復雜查詢條件
    return userRepository.findAll(specification);
}

自定義Listener，玩出花樣

實際專案中，經常會有一種場景，就是需要監聽某個資料的變更然後做一些額外的處理邏輯。一種邏輯，是寫操作的時候順便呼叫下相關業務的處理API，這樣會造成業務間耦合加深；優化點的策略是搞個MQ佇列，然後在這個寫DB操作的同時發個訊息到MQ裡面，然後一堆的consumer會監聽MQ並去做對應的處理邏輯，這樣引入個訊息佇列代價也有點高。

這個時候，我們可以藉助JPA的自定義EntityListener功能來完美解決。通過監聽某個Entity表的變更情況，通知或者呼叫相關其他的業務程式碼處理，完美實現了與主體業務邏輯的解耦，也無需引入其他元件。

舉個例子：現有一個論壇發帖系統，發帖Post和評論Comment屬於兩個相對獨立又有點關係的資料，現在需要檢測當評論變化的時候，需要更新下Post對應記錄的評論數字段。下面演示下具體實現。

  • 首先，定製一個Listener類，並指定Callbacks註解

public class CommentCountAuditListener {
    /**
     *  當Comment表有新增資料的操作時，觸發此方法的呼叫
     */
    @PostPersist
    public void postPersist(CommentEntity entity) {
        // 執行Post表中評論數字段的更新
        // do something here...
    }

    /**
     *  當Comment表有刪除資料的操作時，觸發此方法的呼叫
     */
    @PostRemove
    public void postRemove(CommentEntity entity) {
        // 執行Post表中評論數字段的更新
        // do something here...
    }

    /**
     *  當Comment表有更新資料的操作時，觸發此方法的呼叫
     */
    @PostUpdate
    public void postUpdate(CommentEntity entity) {
        // 執行Post表中評論數字段的更新
        // do something here...
    }
    
}
  • 其次，在評論實體CommentEntity上，加上自定義Listener資訊

@Entity
@Table("t_comment")
// 指定前面定製的Listener
@EntityListeners({CommentCountAuditListener.class})
public class CommentEntity extends AbstractAuditable {
    // ...
}

這樣就搞定了。

自定義Listener還有個典型的使用場景，就是可以統一的記錄DB資料的操作日誌。

定製化SQL，隨心所欲

JPA提供@Query註解，可以實現自定義SQL語句的能力。比如：


@Query(value = "select * from user " +
        "where work_id in (?1) " +
        "and department_id = 0 " +
        "order by CREATE_TIME desc ",
        nativeQuery = true)
List<OssFileInfoEntity> queryUsersByWorkIdIn(List<String> workIds);

如果需要執行寫操作SQL的時候，需要額外增加@Modifying註解標識，如下：


@Modifying
@Query(value = "insert into user (work_id, user_name) values (?1, ?2)",
        nativeQuery = true)
int createUser(String workId, String userName);

其中，nativeQuery = true表示@Query註解中提供的value值為原生SQL語句。如果nativeQuery未設定或者設定為false，則表示將使用JPQL語言來執行。所謂JPQL，即JAVA持久化查詢語句，是一種類似SQL的語法，不同點在於其使用類名來替代表名，使用類欄位來替代表欄位名。比如：


@Query("SELECT u FROM com.vzn.demo.UserInfo u WHERE u.userName = ?1")
public UserInfo getUserInfoByName(String name);

幾個關注點要特別闡述下：

  • like查詢的時候，引數前後的%需要手動新增，系統是不會自動加上的

// like 需要手動新增百分號
@Query("SELECT u FROM com.vzn.demo.UserInfo u WHERE u.userName like %?1")
public UserInfo getUserInfoByName(String name);
  • 使用nativeQuery=true查詢的時候（原生SQL方式），不支援API介面裡面傳入Sort物件然後進行混合執行

// 錯誤示範：  自定義sql與API中Sort引數不可同時混用
@Query("SELECT * FROM t_user u WHERE u.user_name = ?1", nativeQuery=true)
public UserInfo getUserInfoByName(String name, Sort sort);


// 正確示範：  自定義SQL完成對應sort操作
@Query("SELECT * FROM t_user u WHERE u.user_name = ?1 order by ?2", nativeQuery=true)
public UserInfo getUserInfoByName(String name, String sortColumn);
  • 未指定nativeQuery=true查詢的時候(JPQL方式)，支援API介面裡面傳入Sort、PageRequest等物件然後進行混合執行，來完成排序、分頁等操作

// 正確：自定義jpql與API中Sort引數不可同時混用
@Query("SELECT u FROM com.vzn.demo.UserInfo u WHERE u.userName = ?1")
public UserInfo getUserInfoByName(String name, Sort sort);
  • 支援使用引數名作為@Query查詢中的SQL或者JPQL語句的入參，取代引數順序佔位符

預設情況下，引數是通過順序繫結在自定義執行語句上的，這樣如果API介面傳參順序或者位置改變，極易引起自定義查詢傳參出問題，為了解決此問題，我們可以使用@Param註解來繫結一個具體的引數名稱，然後以引數名稱的形式替代位置順序佔位符，這也是比較推薦的一種做法。


// 預設的順序位置傳參
@Query("SELECT * FROM t_user u WHERE u.user_name = ?1 order by ?2", nativeQuery=true)
public UserInfo getUserInfoByName(String name, String sortColumn);

// 使用引數名稱傳參
@Query("SELECT * FROM t_user u WHERE u.user_name = :name order by :sortColumn", nativeQuery=true)
public UserInfo getUserInfoByName(@Param("name") String name, @Param("sortColumn") String sortColumn);

欄位命名對映策略

一般而言，JAVA的編碼規範都要求filed欄位命名需要遵循小駝峰命名的規範，比如userName，而DB中column命名的時候，很多人習慣於使用下劃線分隔的方式命名，比如user_name這種。這樣就涉及到一個對映的策略問題，需要讓JPA知道程式碼裡面的userName就對應著DB中的user_name。

這裡就會涉及到對命名對映策略的對映。主要有兩種對映配置，下面分別闡述下。

  • implicit-strategy

配置項key值：

spring.jpa.hibernate.naming.implicit-strategy=xxxxx

取值說明：

值 對映規則說明
org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImp 預設的命名策略，相容JPA2.0規範
org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl 相容老版本Hibernate的命名規範
org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl 與ImplicitNamingStrategyJpaCompliantImp基本相同
org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl 相容JPA 1.0規範中的命名規範。
org.hibernate.boot.model.naming.SpringImplicitNamingStrategy 繼承ImplicitNamingStrategyJpaCompliantImpl，對外來鍵、連結串列查詢、索引如果未定義，都有下劃線的處理策略，而table和column名字都預設與欄位一樣
  • physical-strategy

配置項key值：

spring.jpa.hibernate.naming.physical-strategy=xxxxx

取值說明：

值 對映規則說明
org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl 預設字串一致對映，不做任何轉換處理，比如java類中userName，對映到table中列名也叫userName
org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy java類中filed名稱小寫字母進行對映到DB表column名稱，遇大寫字母時轉為分隔符"_"命名格式，比如java類中userName欄位，對映到DB表column名稱叫user_name
  • physical-strategy與implicit-strategy

SpringData JPA只是對JPA規範的二次封裝，其底層使用的是Hibernate，所以此處涉及到Hibernate提供的一些處理策略。Hibernate將物件模型對映到關聯式資料庫分為兩個步驟：

  1. 從物件模型中確定邏輯名稱。邏輯名可以由使用者顯式指定(使用@Column或@Table),也可以隱式指定。
  2. 將邏輯名稱對映到物理名稱，也就是資料庫中使用的名稱。

這裡，implicit-strategy用於第一步隱式指定邏輯名稱，而physical-strategy則用於第二步中邏輯名稱到物理名稱的對映。

注意：
當沒有使用@Table和@Column註解時，implicit-strategy配置項才會被使用，即implicit-strategy定義的是一種預設場景的處理策略；而physical-strategy屬於一種高優先順序的策略，只要設定就會被執行，而不管是否有@Table和@Column註解。

小結，承上啟下

好啦，本篇內容就介紹到這裡。

通過本篇的內容，我們對於如何在專案中使用Spring Data JPA來進行一些較為複雜場景的處理方案與策略有了進一步的瞭解，再結合本系列此前的內容，到此掌握的JPA的相關技能已經足以應付大部分專案開發場景。

在實際專案中，為了保障資料操作的可靠、避免髒資料的產生，需要在程式碼中加入對資料庫操作的事務控制。在下一篇文件中，我們將一起聊一聊Spring Data JPA業務程式碼開發中關於資料庫事務的控制，以及編碼中存在哪些可能會導致事務失效的場景等等。

如果對本文有自己的見解，或者有任何的疑問或建議，都可以留言，我們一起探討、共同進步。

補充

Spring Data JPA作為Spring Data中對於關係型資料庫支援的一種框架技術，屬於ORM的一種，通過得當的使用，可以大大簡化開發過程中對於資料操作的複雜度。

本文件隸屬於《Spring Data JPA用法與技能探究》系列的第3篇。本系列文件規劃對Spring Data JPA進行全方位的使用介紹，一共分為5篇文件，如果感興趣，歡迎關注交流。

《Spring Data JPA用法與技能探究》系列涵蓋內容：

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新。

期待與你一起探討，一起成長為更好的自己。

相關文章