前言
一般在寫業(yè)務(wù)接口的過程中，很有可能需要實現(xiàn)可以動態(tài)組合各種查詢條件的接口。如果我們根據(jù)一種查詢條件組合一個方法的做法來寫，那么將會有大量方法存在，繁瑣，維護起來相當(dāng)困難。想要實現(xiàn)動態(tài)查詢，其實就是要實現(xiàn)拼接SQL語句。無論實現(xiàn)如何復(fù)雜，基本都是包括select的字段，from或者join的表，where或者having的條件。在Spring Data JPA有兩種方法可以實現(xiàn)查詢條件的動態(tài)查詢，兩種方法都用到了Criteria API。
Criteria API
這套API可用于構(gòu)建對數(shù)據(jù)庫的查詢。
類型安全。通過定義元數(shù)據(jù)模型，在程序編譯階段就可以對類型進行檢查，不像SQL需要與Mysql進行交互后才能發(fā)現(xiàn)類型問題。
如下即為元數(shù)據(jù)模型。創(chuàng)建一個元模型類，類名最后一個字符為下劃線，內(nèi)部的成員變量與UserInfo.class這個實體類的屬性值相對應(yīng)。
|
1
2
3
4
5
6
7
|
@StaticMetamodel(UserInfo.class)public class UserInfo_ { public static volatile SingularAttribute<UserInfo, Integer> userId; public static volatile SingularAttribute<UserInfo, String> name; public static volatile SingularAttribute<UserInfo, Integer> age; public static volatile SingularAttribute<UserInfo, Long> high;} |
可移植。API并不依賴具體的數(shù)據(jù)庫，可以根據(jù)數(shù)據(jù)庫類型的不同生成對應(yīng)數(shù)據(jù)庫類型的SQL，所以其為可移植的。
面向?qū)ο蟆?/strong>Criteria API是使用的是各種類和對象如CriteriaQuery、Predicate等構(gòu)建查詢，是面向?qū)ο蟮摹６绻苯訒鴮慡QL則相對于面向的是字符串。
第一種:通過JPA的Criteria API實現(xiàn)
- EntityManager獲取CriteriaBuilder
- CriteriaBuilder創(chuàng)建CriteriaQuery
- CriteriaQuery指定要查詢的表，得到Root<UserInfo>，Root代表要查詢的表
- CriteriaBuilder創(chuàng)建條件Predicate，Predicate相對于SQL的where條件，多個Predicate可以進行與、或操作。
- 通過EntityManager創(chuàng)建TypedQuery
- TypedQuery執(zhí)行查詢，返回結(jié)果
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
public class UserInfoExtendDao { @PersistenceContext(unitName = "springJpa") EntityManager em; public List<UserInfo> getUserInfo(String name,int age,int high) { CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<UserInfo> query = cb.createQuery(UserInfo.class); //from Root<UserInfo> root = query.from(UserInfo.class); //where Predicate p1 = null; if(name!=null) { Predicate p2 = cb.equal(root.get(UserInfo_.name),name); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } if(age!=0) { Predicate p2 = cb.equal(root.get(UserInfo_.age), age); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } if(high!=0) { Predicate p2 = cb.equal(root.get(UserInfo_.high), high); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } query.where(p1); List<UserInfo> userInfos = em.createQuery(query).getResultList(); return userInfos; }} |
第二種:DAO層接口實現(xiàn)JpaSpecificationExecutor<T>接口
JpaSpecificationExecutor如下，方法參數(shù)Specification接口有一個方法toPredicate，返回值正好是Criteria API中的Predicate，而Predicate相對于SQL的where條件。與上一個方法相比，這種寫法不需要指定查詢的表是哪一張，也不需要自己通過Criteria API實現(xiàn)排序和分頁，只需要通過新建Pageable、Sort對象并傳參給findAll方法即可，簡便一些。
|
1
2
3
4
5
6
7
|
public interface JpaSpecificationExecutor<T> { T findOne(Specification<T> spec); List<T> findAll(Specification<T> spec); Page<T> findAll(Specification<T> spec, Pageable pageable); List<T> findAll(Specification<T> spec, Sort sort); long count(Specification<T> spec);} |
UserInfoDao實現(xiàn)JpaSpecificationExecutor
|
1
2
|
public interface UserInfoDao extends PagingAndSortingRepository<UserInfo, String>, JpaSpecificationExecutor<UserInfo> {} |
實現(xiàn)Specification
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
public static Specification<UserInfo> getSpec(final String name,final int age,final int high) { return new Specification<UserInfo>() { @Override public Predicate toPredicate(Root<UserInfo> root, CriteriaQuery<?> query, CriteriaBuilder cb) { Predicate p1 = null; if(name!=null) { Predicate p2 = cb.equal(root.get(UserInfo_.name),name); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } if(age!=0) { Predicate p2 = cb.equal(root.get(UserInfo_.age), age); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } if(high!=0) { Predicate p2 = cb.equal(root.get(UserInfo_.high), high); if(p1 != null) { p1 = cb.and(p1,p2); } else { p1 = p2; } } return p1; } }; } |
以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持服務(wù)器之家。
原文鏈接：http://www.jianshu.com/p/45ad65690e33#
