4 綜合查詢進階【后】 · SpringBoot+Angular入門實例教程

在上個小節中我們使用單元測試的方法學習了綜合查詢。這在學習過程中是無可厚非的，但卻不是單元測試的正規用法。單元測試更多的是用于保障自己某個方法功能的正確性，而非來其它方法。學習某個知識點最佳的方法是按官方的推薦建立個小的demo，然后在demo中添加模擬數據，并在模擬數據的基礎上按官方的指導進行練習。在進行綜合查詢時，我們往往會將其抽離成單元的包，并在包中針對每個實體建立單元的類。 # 初始化綜合查詢的包起名為specs，我們在repository下建立specs包，并在該包中建立StudentSpecs.java ``` panjiedeMac-Pro:mengyunzhi panjie$ tree . └── springBootStudy ├── SpringBootStudyApplication.java ├── config │?? └── WebConfig.java ├── controller │?? ├── KlassController.java │?? ├── StudentController.java │?? └── TeacherController.java ├── entity │?? ├── Klass.java │?? ├── Student.java │?? └── Teacher.java ├── repository │?? ├── KlassRepository.java │?? ├── StudentRepository.java │?? ├── TeacherRepository.java │?? └── specs │?? └── StudentSpecs.java ★ └── service ├── KlassService.java ├── KlassServiceImpl.java ├── StudentService.java └── StudentServiceImpl.java ``` 編輯該文件，并建立以下靜態（依賴于類而不依賴于具體的對象）方法以完成條件查詢功能: # 查詢條件：班級在實體的設置中，學生與班的關系是：學生`屬于`某個班級。因而在綜合查詢的方法中，我們對應將其查詢方法命名為：belongToKlass repository/specs/StudentSpecs.java ``` /** * 學生綜合查詢 * */ public class StudentSpecs { /** * 屬于某個班級 * @param klass 班級 * @return */ public static Specification<Student> belongToKlass(Klass klass?) { return new Specification<Student>() { @Override public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> criteriaQuery, CriteriaBuilder criteriaBuilder) { return criteriaBuilder.equal(root.get("klass").as(Klass.class), klass?); } }; } } ``` * ? 將查詢條件Klass做為靜態方法的參數傳入 * ? 構建給定查詢時，直接使用該傳入參數 ## 單元測試使用IDEA自對生成對應的測試文件StudentSpecTest.java ``` @SpringBootTest @RunWith(SpringRunner.class) public class StudentSpecsTest { private static final Logger logger = LoggerFactory.getLogger(StudentSpecsTest.class); @Autowired private KlassRepository klassRepository; @Autowired private StudentRepository studentRepository; @Test public void belongToKlass() { logger.info("初始化測試數據"); Klass klass = new Klass(); klass.setName("testKlass"); this.klassRepository.save(klass); Student student = new Student(); student.setName("testName"); student.setSno("032282"); student.setKlass(klass); this.studentRepository.save(student); List students = this.studentRepository.findAll(StudentSpecs.belongToKlass(klass)); ① Assertions.assertThat(students.size()).isEqualTo(1);① klass.setId(-1L); ② students = this.studentRepository.findAll(StudentSpecs.belongToKlass(klass)); ② Assertions.assertThat(students.size()).isEqualTo(0); ② } } ``` * ① 以klass進行綜合查詢，斷言條數為1 * ② 將klass的ID設置為-1，斷言查詢的條數為0。預測：jpa是根據關聯實體的ID值進行查詢的 # 查詢條件：姓名查詢姓名的方法我們命名為：containingName，顧名思義：只要姓名中包含有某個關鍵字，即為符合條件。 ``` public class StudentSpecs { ... public static Specification<Student>? containingName(String name) { return new Specification<Student>()? { @Override public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> criteriaQuery, CriteriaBuilder criteriaBuilder)? { return criteriaBuilder.like(root.get("name").as(String.class), String.format("%%%s%%?", name)); } }; } } ``` * ? 在字符串格式化時，由于%是其關鍵字，所以想表示該`%`為字符串的文本時，需要將`%`轉義為`%%`。所以當name為`zhangsan`時，上述格式代碼將格式化為`%zhangsan%` 由于在方法中的返回值中規定了類型Specification<Student>?，所以在書寫時即使我們刪除new Specification<Student>()?代碼，也不會造成誤解；又由于Specification接口中僅聲明了一個方法?，所以即使我們不書寫該方法名，編譯器也知道我們必然是實現的該方法，故以上方法還可以簡寫為： ``` public class StudentSpecs { ... public static Specification<Student> containingName(String name) { return (Specification<Student>) (root, criteriaQuery, criteriaBuilder) -> { return criteriaBuilder.like(root.get("name").as(String.class), String.format("%%%s%%", name)); ? }; } } ``` 又由于return?的代碼僅有一行，而又同時聲明了方法的返回值類型，所以即使不寫return，編譯器也知道我們要返回這行代碼的結果，所以上述代碼又可以進行下簡寫為： ``` public class StudentSpecs { ... public static Specification<Student> containingName(String name) { return (Specification<Student>) (root, criteriaQuery, criteriaBuilder) -> criteriaBuilder.like(root.get("name").as(String.class), String.format("%%%s%%", name)); } } ``` 而上述簡寫后的代碼稱為：lambda表過式。 ## 單元測試由于本功能的測試也需要進行數據的初始化工作，所以在進行編碼前先對原測試代碼進行小幅度重構： StudentSpecsTest.java ``` private Student student; ? @Before public void before() { logger.info("初始化測試數據"); Klass klass = new Klass(); klass.setName("testKlass"); this.klassRepository.save(klass); this.student = new Student(); ? this.student.setName("testName"); this.student.setSno("032282"); this.student.setKlass(klass); this.studentRepository.save(this.student); } @Test public void belongToKlass() { Klass klass = this.student.getKlass(); ? List students = this.studentRepository.findAll(StudentSpecs.belongToKlass(klass)); ``` 重構后再次執行belongToKlass測試，以保障重構未對歷史的單元測試功能造成影響。然后開始書寫本測試： ``` @SpringBootTest @RunWith(SpringRunner.class) public class StudentSpecsTest { ... /** * name測試 * 1. 原文 * 2. left * 3. middle * 4. right * 5. 不包含 */ @Test public void containingName() { List students = this.studentRepository.findAll(StudentSpecs.containingName("testName")); Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.containingName("tes")); Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.containingName("stNa")); Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.containingName("tName")); Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.containingName("testName12")); Assertions.assertThat(students.size()).isEqualTo(0); } } ``` * 在測試中，我們分別對原文、以部分關鍵字開始、關鍵字取中、以部分關鍵字結束以及不符合的條件分別進行了測試，以此來保障代碼的健壯性 # 條件查詢：sno 有了剛剛的經驗，對學號的條件查詢便很輕松了，方法我們命名為startWithSno StudentSpecs.java ``` public class StudentSpecs { ... public static Specification<Student> startWithSno(String sno) { return (Specification<Student>) (root, criteriaQuery, criteriaBuilder) -> criteriaBuilder.like(root.get("sno").as(String.class), String.format("%s%%①", sno)); } } ``` * ① 以%結尾 ## 單元測試 ``` @SpringBootTest @RunWith(SpringRunner.class) public class StudentSpecsTest { ... /** * sno測試 * 1. 原文 * 2. 左 * 3. 中 */ @Test public void startWithSno() { List students = this.studentRepository.findAll(StudentSpecs.startWithSno("032282")); ① Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.startWithSno("032")); ② Assertions.assertThat(students.size()).isEqualTo(1); students = this.studentRepository.findAll(StudentSpecs.startWithSno("3228")); ③ Assertions.assertThat(students.size()).isEqualTo(0); } ... } ``` * ① 原文 * ② 以部分關鍵字開始 * ③ 取中，斷言取出0條 # 組合查詢有了上述三個查詢條件后，便可以輕驗的使用他們來進行組合查詢了。按分層的理論，對數據進行查詢的基礎操作應該屬于repository，所以打開repository/StudentRepository.java，并新建如下方法： ``` /** * 綜合查詢 * @param name containing 姓名 * @param sno startWith 學號 * @param klass equal 班級 * @param pageable * @return */ default? Page findAll(String name, String sno, Klass klass, Pageable pageable) { Specification<Student> specification = StudentSpecs.containingName(name) ? .and(StudentSpecs.startWithSno(sno)) ? .and(StudentSpecs.belongToKlass(klass)); ? return this?.findAll(specification, pageable); } ``` * ? 在接口中的方法需要用default進行修飾 * ? this表示本(實現了這個接口的)對象我們此時的需求是三個條詢條件做`交集`，所以是`并 and`的關系，對應查詢條件為：`? and ? and ?` ## 單元測試每個單元測試均應著重測試對應方法的功能，在本方法中StudentSpecs.containingName方法屬于方法調用，原則上并不在我們的測試范圍以內，本測試應該著重測試的是三個查詢條件是否生效以及三個查詢條件間的關系是否為`and` 打開repository/StudentRepositoryTest.java，在原findAll方法的基礎上繼續進行測試： ``` @Test public void findAll() { List<Student> oldStudentList = (List<Student>) this.studentRepository.findAll(); /* 初始化2個班級并持久化*/ Klass klass = new Klass(); klass.setName("testKlass"); this.klassRepository.save(klass); Klass klass1 = new Klass(); klass1.setName("testKlass1"); this.klassRepository.save(klass1); Student student = new Student(); student.setName("testStudentName"); student.setSno("032282"); student.setKlass(klass); this.studentRepository.save(student); /* 初始化2個不同班級的學生并持久化 */ Student student1 = new Student(); student1.setName("testStudentName1"); student1.setSno("032291"); student1.setKlass(klass1); this.studentRepository.save(student1); Page studentPage = this.studentRepository.findAll("testStudentName", "032282", klass, PageRequest.of(0, 2)); ① Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(1); studentPage = this.studentRepository.findAll("testStudentName12", "032282", klass, PageRequest.of(0, 2)); ② Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(0); studentPage = this.studentRepository.findAll("testStudentName", "0322821", klass, PageRequest.of(0, 2)); ③ Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(0); studentPage = this.studentRepository.findAll("testStudentName", "032282", klass1, PageRequest.of(0, 2)); ④ Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(0); } ``` * ① 加入全部查詢字段 * ② 變更name值后查詢到0條，說明name字段在查詢中生效了同時查詢條件為and的關系 * ③ sno字段，原理同上 * ④ klass字段，原理同上單元測試通過，說明功能代碼正確。 # NULL 前面我們在棄用第一種方法的時候給出的理由是該方法并不支持null值。那么第二種的綜合查詢方法是否支持傳入null呢？我們在原測試的基礎上加入對null值的測試： repository/StudentRepositoryTest.java ``` @Test public void findAll() { ... studentPage = this.studentRepository.findAll("testStudentName", "032282", klass1, PageRequest.of(0, 2)); Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(0); studentPage = this.studentRepository.findAll(null, "032282", klass, PageRequest.of(0, 2)); logger.info("傳入的name為null, 得到了{}條數據", studentPage.getTotalElements()); } ``` 測試結果為： ``` 2019-11-29 14:48:38.495 INFO 51728 --- [ main] c.m.s.repository.StudentRepositoryTest : 傳入的name為null, 得到了0條數據 ``` 該語句沒有報異常，當name為null，返回了0條數據。這是由于JPA在進行綜合查詢時，當接收到值為null的name時，在查詢過程中會生成類似于`name is null`的語句。但這明顯與我們實際需求的并不相同。我們的需求是：當用戶未傳入name，即name的值為null時，應該忽略該name條件。而不是查詢name為null的記錄。 ## 處理NULL 我們在程序編寫時有一個不成文的規則：如果未標明該參數不能為null，那么表示該參數可以為null;如果該參數不能為null，那么需要使用`@NotNull`來標注。是否允許參數為null，要根據現實的情況來設定。比如我們此時在進行綜合查詢時，調用者是需求將name為null的值傳入的，那么就該name就必須可以為null，而我們要做的則是對null值進行處理。但既然是分頁查詢，那么規定用戶必須傳入分頁的條件信息。對name的null處理，我們放到repository/specs/StudentSpec.java中 ``` public class StudentSpecs { ... public static Specification<Student> containingName(String name) { if (name != null) { ① return (Specification<Student>) (root, criteriaQuery, criteriaBuilder) -> criteriaBuilder.like(root.get("name").as(String.class), String.format("%%%s%%", name)); } else { return Specification.where(null); ② } } ... } ``` * ① 對參數值進行null判斷 * ② 當參數為null時，返回一個空規范，該空規范不在查詢中起任何作用此時我們重新進行單元測試： ``` 2019-11-29 15:03:25.004 INFO 63864 --- [ main] c.m.s.repository.StudentRepositoryTest : 傳入的name為null, 得到了1條數據 ``` 則在查詢條件中當name為null做的是忽略處理，而非null查詢。 > 注意：在StudentRepositoryTest中來測試StudentSpec代碼是正確性是錯誤的，請自行修正。 ### sno的null處理 sno的處理方式與name的方式相同，請自行完成。 ### klass的null處理 jpa在進行關聯查詢時，實際上查詢的是關聯實體的主鍵值信息，也就是說：當傳入klass時，JPA是依據klass的id值來進行查詢的，如果未傳入id， ``` @Test public void findAll() { ... studentPage = this.studentRepository.findAll(null, null, new Klass()★, PageRequest.of(0, 2)); Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(1); ``` 在進行相關的查詢時便會報以下異常信息： ``` org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.mengyunzhi.springBootStudy.entity.Klass; nested exception is java.lang.IllegalStateException: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.mengyunzhi.springBootStudy.entity.Klass ``` 他大體是說：你即然要以klass為查詢條件對student表進行查詢，那么klass最少得是咱數據表中存在的數據吧（如果不存在klass，是不可能將其設置為student的外鍵值的）。所以我們還需要對klass及其id值是否為null進行處理: repository/specs/StudentSpecs.java ``` public static Specification<Student> belongToKlass(Klass klass) { if (null == klass || null == klass.getId()) { return Specification.where(null); } return (Specification<Student>) (root, criteriaQuery, criteriaBuilder) -> criteriaBuilder.equal(root.get("klass").as(Klass.class), klass); } ``` ### pageable的null處理前面三個參數均進行了null的處理，當方法`default Page findAll(String name, String sno, Klass klass, Pageable pageable) {`中的第四個參數為null時，JPA會為我們自動處理嗎？我們繼續增加測試語句： ``` @Test public void findAll() { ... studentPage = this.studentRepository.findAll(null, null, null, null); Assertions.assertThat(studentPage.getTotalElements()).isEqualTo(2); ``` 運行測試則得到以下異常： ``` 2019-11-29 15:22:04.815 INFO 79226 --- [ main] o.h.h.i.QueryTranslatorFactoryInitiator : HHH000397: Using ASTQueryTranslatorFactory java.lang.NullPointerException ``` 這是個空指針異常，該異常是在程序執行時在調用某個對象的某個方法時，由于該對象為null產生的。也就是說pageable為null也是不可行的。做為一個負責任的開發者，我們需要用更人性化的方式來告知我們團隊的其它成員pageable是不能夠為null的. #### @NotNull 最基本的，我們需要在參數上添加一個`@NotNull`注解來表時該參數是不可以為null的。 ``` import javax.validation.constraints.NotNull; ... public interface StudentRepository extends PagingAndSortingRepository<Student, Long>, JpaSpecificationExecutor { ... default Page findAll(String name, String sno, Klass klass, @NotNull? Pageable pageable) { ... } } ``` * ? 告知隊友：該參數不能為null 雖然我們在此明確的告知隊友說：該參數不能為null。但有時候不怕神一樣的對手...。@NotNull的作用僅僅是`mark 標記`，除此之外，它什么作用都沒有。當然也就不能夠指望說在隊友傳入null時，編譯器會報異常了（實質上除非是顯性的傳入null，編譯器是無法判斷傳入的值是否可能為null的）。 #### 異常使用異常的方式來告知隊友我們是不支持null的可以降低他調用我們產生空指針錯誤的排錯難度，雖然說即使我們什么也不做，有經驗的隊友在調用我們發生null異常時仍然可以根據異常及我們的代碼來判斷出具體是出了什么問題，但這種做法總歸是不負責任的。這就像我們該死的中國聯通，A處理業務時發生了錯誤，然后告知你去哪哪哪找B，到了B那又告知你去哪哪找C，最后C再讓你去找A。做為客戶的我們，更希望的是"首問負責制"，也就說我調用你發生的問題，你就應該直接告訴我怎么解決，而不是讓客戶去替你DEBUG。 ``` public interface StudentRepository extends PagingAndSortingRepository<Student, Long>, JpaSpecificationExecutor { default Page findAll(String name, String sno, Klass klass, @NotNull Pageable pageable) { if (null == pageable) { throw new IllegalArgumentException("傳入的Pageable不能為null"); ? } ... ``` * ? 當接收的參數為null，拋出`非法參數異常` 此時當我們繼續以null調用時： ``` @Test public void findAll() ... studentPage = this.studentRepository.findAll(null, null, null, null); ``` 則會得到如下異常提示： ``` org.springframework.dao.InvalidDataAccessApiUsageException: 傳入的Pageable不能為null; nested exception is java.lang.IllegalArgumentException: 傳入的Pageable不能為null ``` 同時，我們還可以在控制臺中找到該異常的位置： ![](https://img.kancloud.cn/67/ae/67ae7ed2603f6942a73042a3e39c1bb4_1343x130.png) 由于該參數異常是較常規的寫法，所以spring友好的為我們進行了封裝，當進行參數的異常聲明時，我們也可以這樣： ``` import org.springframework.util.Assert; ... public interface StudentRepository extends PagingAndSortingRepository<Student, Long>, JpaSpecificationExecutor { default Page findAll(String name, String sno, Klass klass, @NotNull Pageable pageable) { Assert.notNull(pageable, "傳入的Pageable不能為null"); ? if (null == pageable) { ? throw new IllegalArgumentException("傳入的Pageable不能為null"); ? } ? ``` 效果相同。最后我們進行異常測試。測試該異常的方法有兩種：第一種是在已經長的不行的findAll方法上再加入幾行，并用try catch來進行捕獲；第二種是單獨在建立一個測試用例來專門測試異常。一般情況下，我們更習慣于使用第一種；而使用第二種也是正確的做法。在單元測試時，力求將測試的粒度最小化，把各個測試用例需要用到的具有共性的代碼抽離到@Before方法中，然后在各個測試用例中盡量只測試一個簡單到不能分解的功能。這樣的做的好處最少有兩點：1. 由于每次只測一小點，所以可以減小我們測試時的思維量，避免燒腦；2. 當單元測試發生錯誤時，由于測試代碼的行數較長，所以修正代碼的工作量也會很小。在一般的風格指南或是開發規范上都會以類似的話術：如果一個函數內的代碼行數超過40行，便可以思索一下能不能在不影響程序結構的前提下對其進行分割了。原文對于長函數是這么解釋的： <hr /> 我們承認長函數有時是合理的, 因此并不硬性限制函數的長度. 如果函數超過 40 行, 可以思索一下能不能在不影響程序結構的前提下對其進行分割. 即使一個長函數現在工作的非常好, 一旦有人對其修改, 有可能出現新的問題, 甚至導致難以發現的 bug. 使函數盡量簡短, 以便于他人閱讀和修改代碼. 在處理代碼時, 你可能會發現復雜的長函數. 不要害怕修改現有代碼: 如果證實這些代碼使用 / 調試起來很困難, 或者你只需要使用其中的一小段代碼, 考慮將其分割為更加簡短并易于管理的若干函數. <hr /> ``` import org.springframework.dao.InvalidDataAccessApiUsageException; ? @SpringBootTest @RunWith(SpringRunner.class) public class StudentRepositoryTest { ... @Test(expected = InvalidDataAccessApiUsageException.class) public void findAllWithPageableIsNull() { this.studentRepository.findAll("name", "sno", new Klass(), null); } ``` * ? 此處需要捕獲InvalidDataAccessApiUsageException而非IllegalArgumentException（spring對其進行了封裝），了解即可。 # 總結本小節我們費勁周折，目標就是在學生倉庫中建立一個可以支持多字段綜合查詢及分頁的findAll方法。一旦有了此方法的支持，我們便可以輕松的service中對其進行調用，進而實現對學生表的綜合查詢。在程序的編寫過程中，我們進行了充分的分層及單元測試、友好的null提示，目標僅為一個：**編寫易讀、友好、易維護的代碼。** # 參考文檔 | 名稱 | 鏈接 | 預計學習時長(分） | | --- | --- | --- | | 源碼地址 | [https://github.com/mengyunzhi/spring-boot-and-angular-guild/releases/tag/step4.6.4](https://github.com/mengyunzhi/spring-boot-and-angular-guild/releases/tag/step4.6.4) | - |