我这样写代码，比直接使用 MyBatis 效率提高了 100 倍
今日推薦
扔掉 Postman，一個工具全部搞定，真香！為啥查詢那么慢？還在直接用JWT做鑒權？JJWT真香推薦 15 款常用開發工具干掉 navicat：這款 DB 管理工具才是y(永)y(遠)d(的)s(神)對一個 Java 后端程序員來說，mybatis、hibernate、data-jdbc 等都是我們常用的 ORM 框架。它們有時候很好用，比如簡單的 CRUD，事務的支持都非常棒。但有時候用起來也非常繁瑣，比如接下來我們要聊到的一個常見的開發需求，而對這類需求，本文會給出一個比直接使用這些 ORM 開發效率至少會提高 100 倍的方法（絕無夸張）。
首先數據庫有兩張表
用戶表（user）：（簡單起見，假設只有 4 個字段）
角色表（role）：（簡單起見，假設只有 2 個字段）
接下來我們要實現一個用戶查詢的功能
這個查詢有點復雜，它的要求如下：
可按用戶名字段查詢，要求：
可精確匹配（等于某個值）
可全模糊匹配（包含給定的值）
可后模糊查詢（以...開頭）
可前模糊查詢（以.. 結尾）
可指定以上四種匹配是否可以忽略大小寫
可按年齡字段查詢，要求：
可精確匹配（等于某個年齡）
可大于匹配（大于某個值）
可小于匹配（小于某個值）
可區間匹配（某個區間范圍）
可按角色ID查詢，要求：精確匹配
可按用戶ID查詢，要求：同年齡字段
可指定只輸出哪些列（例如，只查詢 ID 與 用戶名 列）
支持分頁（每次查詢后，頁面都要顯示滿足條件的用戶總數）
查詢時可選擇按 ?ID、用戶名、年齡 等任意字段排序
后端接口該怎么寫呢？
試想一下，對于這種要求的查詢，后端接口里的代碼如果用 mybatis、hibernate、data-jdbc 直接來寫的話，100 行代碼 能實現嗎？
反正我是沒這個信心，算了，我還是直接坦白，面對這種需求后端如何 只用一行代碼搞定 吧（有興趣的同學可以 mybatis 等寫個試試，最后可以對比一下）
手把手：只一行代碼實現以上需求
首先，重點人物出場啦：Bean Searcher, ?它就是專門來對付這種列表檢索的，無論簡單的還是復雜的，統統一行代碼搞定！而且它還非常輕量，Jar 包體積僅不到 100KB，無第三方依賴。
假設我們項目使用的框架是 Spring Boot（當然 Bean Searcher 對框架沒有要求，但在 Spring Boot 中使用更加方便）
添加依賴
Maven ：
<dependency><groupId>com.ejlchina</groupId><artifactId>bean-searcher-boot-starter</artifactId><version>3.0.1</version> </dependency>Gradle ：
implementation?'com.ejlchina:bean-searcher-boot-starter:3.0.1'然后寫個實體類來承載查詢的結果
@SearchBean(tables="user?u,?role?r",?joinCond="u.role_id?=?r.id",?autoMapTo="u")? public?class?User?{private?Long?id;??//?用戶ID（u.id）private?String?name;?//?用戶名（u.name）private?int?age;??//?年齡（u.age）private?int?roleId;??//?角色ID（u.role_id）@DbField("r.name")??//?指明這個屬性來自?role?表的?name?字段private?int?role;??//?角色名（r.name）//?Getter?and?Setter?... }接著就可以寫用戶查詢接口了
接口路徑就叫 /user/index 吧：
@RestController @RequestMapping("/user") public?class?UserController?{@Autowiredprivate?MapSearcher?mapSearcher;??//?注入檢索器（由?bean-searcher-boot-starter?提供）@GetMapping("/index")public?SearchResult<Map<String,?Object>>?index(HttpServletRequest?request)?{//?這里咱們只寫一行代碼return?mapSearcher.search(User.class,?MapUtils.flat(request.getParameterMap()));}}上述代碼中的 MapUtils 是 Bean Searcher 提供的一個工具類，MapUtils.flat(request.getParameterMap()) 只是為了把前端傳來的請求參數統一收集起來，然后剩下的，就全部交給 MapSearcher 檢索器了。
這樣就完了？那我們來測一下這個接口，看看效果吧
（1）無參請求
GET /user/index
返回結果：
（2）分頁請求（page | size）
GET /user/index? page=2 & size=10
返回結果：結構同 （1）（只是每頁 10 條，返回第 2 頁）
參數名 size 和 page 可自定義， page 默認從 0 開始，同樣可自定義，并且可與其它參數組合使用
（3）數據排序（sort | order）
GET /user/index? sort=age & order=desc
返回結果：結構同 （1）（只是 dataList 數據列表以 age 字段降序輸出）
參數名 sort 和 order 可自定義，可與其它參數組合使用
（4）指定（排除）字段（onlySelect | selectExclude）
GET /user/index? onlySelect=id,name,role
GET /user/index? selectExclude=age,roleId
返回結果：（ 列表只含 id,name 與 role 三個字段）
參數名 onlySelect 和 selectExclude 可自定義，可與其它參數組合使用
（5）字段過濾（op = eq）
GET /user/index? age=20
GET /user/index? age=20 & age-op=eq
返回結果：結構同 （1）（但只返回 age = 20 的數據）
參數 age-op = eq 表示 age 的 字段運算符 是 eq（Equal 的縮寫），表示參數 age 與參數值 20 之間的關系是 Equal，由于 Equal 是一個默認的關系，所以 age-op = eq 也可以省略
參數名 age-op 的后綴 -op 可自定義，且可與其它字段參數 和 上文所列的參數（分頁、排序、指定字段）組合使用，下文所列的字段參數也是一樣，不再復述。
（6）字段過濾（op = ne）
GET /user/index? age=20 & age-op=ne
返回結果：結構同 （1）（但只返回 age != 20 的數據，ne 是 NotEqual 的縮寫）
（7）字段過濾（op = ge）
GET /user/index? age=20 & age-op=ge
返回結果：結構同 （1）（但只返回 age >= 20 的數據，ge 是 GreateEqual 的縮寫）
（8）字段過濾（op = le）
GET /user/index? age=20 & age-op=le
返回結果：結構同 （1）（但只返回 age <= 20 的數據，le 是 LessEqual 的縮寫）
（9）字段過濾（op = gt）
GET /user/index? age=20 & age-op=gt
返回結果：結構同 （1）（但只返回 age > 20 的數據，gt 是 GreateThan 的縮寫）
（10）字段過濾（op = lt）
GET /user/index? age=20 & age-op=lt
返回結果：結構同 （1）（但只返回 age < 20 的數據，lt 是 LessThan 的縮寫）
（11）字段過濾（op = bt）
GET /user/index? age-0=20 & age-1=30 & age-op=bt
返回結果：結構同 （1）（但只返回 20 <= age <= 30 的數據，bt 是 Between 的縮寫）
參數 age-0 = 20 表示 age 的第 0 個參數值是 20。上述提到的 age = 20 實際上是 age-0 = 20 的簡寫形式。另：參數名 age-0 與 age-1 中的連字符 - 可自定義。
（12）字段過濾（op = mv）
GET /user/index? age-0=20 & age-1=30 & age-2=40 & age-op=mv
返回結果：結構同 （1）（但只返回 age in (20, 30, 40) 的數據，mv 是 MultiValue 的縮寫，表示有多個值的意思）
（13）字段過濾（op = in）
GET /user/index? name=Jack & name-op=in
返回結果：結構同 （1）（但只返回 name 包含 Jack 的數據，in 是 Include 的縮寫）
（14）字段過濾（op = sw）
GET /user/index? name=Jack & name-op=sw
返回結果：結構同 （1）（但只返回 name 以 Jack 開頭的數據，sw 是 StartWith 的縮寫）
（15）字段過濾（op = ew）
GET /user/index? name=Jack & name-op=ew
返回結果：結構同 （1）（但只返回 name 以 Jack 結尾的數據，sw 是 EndWith 的縮寫）
（16）字段過濾（op = ey）
GET /user/index? name-op=ey
返回結果：結構同 （1）（但只返回 name 為空 或為 null 的數據，ey 是 Empty 的縮寫）
（17）字段過濾（op = ny）
GET /user/index? name-op=ny
返回結果：結構同 （1）（但只返回 name 非空 的數據，ny 是 NotEmpty 的縮寫）
（18）忽略大小寫（ic = true）
GET /user/index? name=Jack & name-ic=true
返回結果：結構同 （1）（但只返回 name 等于 Jack (忽略大小寫) 的數據，ic 是 IgnoreCase 的縮寫）
參數名 name-ic 中的后綴 -ic 可自定義，該參數可與其它的參數組合使用，比如這里檢索的是 name 等于 Jack 時忽略大小寫，但同樣適用于檢索 name 以 Jack 開頭或結尾時忽略大小寫。
當然，以上各種條件都可以組合，例如
查詢 name 以 Jack (忽略大小寫) 開頭，且 roleId = 1，結果以 id 字段排序，每頁加載 10 條，查詢第 2 頁：
GET /user/index? name=Jack & name-op=sw & name-ic=true & roleId=1 & sort=id & size=10 & page=2
返回結果：結構同 （1）
OK，效果看完了，/user/index 接口里我們確實只寫了一行代碼，它便可以支持這么多種的檢索方式，有沒有覺得現在 你寫的一行代碼 就可以 干過別人的一百行 呢？
Bean Searcher
本例中，我們只使用了 Bean Searcher 提供的 MapSearcher 檢索器的一個 search 方法，其實，它有很多 search 方法。
檢索方法
searchCount(Class<T> beanClass, Map<String, Object> params) 查詢指定條件下的數據 總條數
searchSum(Class<T> beanClass, Map<String, Object> params, String field) 查詢指定條件下的 某字段 的 統計值
searchSum(Class<T> beanClass, Map<String, Object> params, String[] fields) 查詢指定條件下的 多字段 的 統計值
search(Class<T> beanClass, Map<String, Object> params) 分頁 查詢指定條件下數據 列表 與 總條數
search(Class<T> beanClass, Map<String, Object> params, String[] summaryFields) 同上 + 多字段 統計
searchFirst(Class<T> beanClass, Map<String, Object> params) 查詢指定條件下的 第一條 數據
searchList(Class<T> beanClass, Map<String, Object> params) 分頁 查詢指定條件下數據 列表
searchAll(Class<T> beanClass, Map<String, Object> params) 查詢指定條件下 所有 數據 列表
MapSearcher 與 BeanSearcher
另外，Bean Searcher 除了提供了 MapSearcher 檢索器外，還提供了 BeanSearcher 檢索器，它同樣擁有 MapSearcher 擁有的方法，只是它返回的單條數據不是 Map，而是一個 泛型 對象。
參數構建工具
另外，如果你是在 Service 里使用 Bean Searcher，那么直接使用 Map<String, Object> 類型的參數可能不太優雅，為此， Bean Searcher 特意提供了一個參數構建工具。
例如，同樣查詢 name 以 Jack (忽略大小寫) 開頭，且 roleId = 1，結果以 id 字段排序，每頁加載 10 條，加載第 2 頁，使用參數構建器，代碼可以這么寫：
Map<String,?Object>?params?=?MapUtils.builder().field(User::getName,?"Jack").op(Operator.StartWith).ic().field(User::getRoleId,?1).orderBy(User::getId,?"asc").page(2,?10).build() List<User>?users?=?beanSearcher.searchList(User.class,?params);這里使用的是 BeanSearcher 檢索器，以及它的 searchList(Class<T> beanClass, Map<String, Object> params) 方法。
運算符約束
上文我們看到，Bean Searcher 對實體類中的每一個字段，都直接支持了很多的檢索方式。
但某同學：哎呀！檢索方式太多了，我根本不需要這么多，我的數據量幾十億，用戶名字段的前模糊查詢方式利用不到索引，萬一把我的數據庫查崩了怎么辦呀？
好辦，Bean Searcher 支持運算符的約束，實體類的用戶名 name 字段只需要注解一下即可：
@SearchBean(tables="user?u,?role?r",?joinCond="u.role_id?=?r.id",?autoMapTo="u")? public?class?User?{@DbField(onlyOn?=?{Operator.Equal,?Operator.StartWith})private?String?name;//?為減少篇幅，省略其它字段... }如上，通過 @DbField 注解的 onlyOn 屬性，指定這個用戶名 name 只能適用與 精確匹配 和 后模糊查詢，其它檢索方式它將直接忽略。
上面的代碼是限制了 name 只能有兩種檢索方式，如果再嚴格一點，只允許 精確匹配，那其實有兩種寫法。
（1）還是使用運算符約束：
@SearchBean(tables="user?u,?role?r",?joinCond="u.role_id?=?r.id",?autoMapTo="u")? public?class?User?{@DbField(onlyOn?=?Operator.Equal)private?String?name;//?為減少篇幅，省略其它字段... }（2）在 Controller 的接口方法里把運算符參數覆蓋：
@GetMapping("/index") public?SearchResult<Map<String,?Object>>?index(HttpServletRequest?request)?{Map<String,?Object>?params?=?MapUtils.flatBuilder(request.getParameterMap()).field(User::getName).op(Operator.Equal)???//?把?name?字段的運算符直接覆蓋為?Equal.build()return?mapSearcher.search(User.class,?params); }條件約束
該同學又：哎呀！我的數據量還是很大，age 字段沒有索引，我不想讓它參與 where 條件，不然很可能就出現慢 SQL 啊！
不急，Bean Searcher 還支持條件的約束，讓這個字段直接不能作為條件：
@SearchBean(tables="user?u,?role?r",?joinCond="u.role_id?=?r.id",?autoMapTo="u")? public?class?User?{@DbField(conditional?=?false)private?int?age;//?為減少篇幅，省略其它字段... }如上，通過 @DbField 注解的 conditional 屬性， 就直接不允許 age 字段參與條件了，無論前端怎么傳參，Bean Searcher 都不搭理。
參數過濾器
該同學仍：哎呀！哎呀 ...
別怕！ Bean Searcher 還支持配置全局參數過濾器，可自定義任何參數過濾規則，在 Spring Boot 項目中，只需要配置一個 Bean：
@Bean public?ParamFilter?myParamFilter()?{return?new?ParamFilter()?{@Overridepublic?<T>?Map<String,?Object>?doFilter(BeanMeta<T>?beanMeta,?Map<String,?Object>?paraMap)?{//?beanMeta?是正在檢索的實體類的元信息,?paraMap?是當前的檢索參數//?TODO:?這里可以寫一些自定義的參數過濾規則return?paraMap;??????//?返回過濾后的檢索參數}}; }某同學問
參數咋這么怪，這么多呢，和前端有仇么
參數名是否奇怪，這其實看個人喜好，如果你不喜歡中劃線 -，不喜歡 op、ic 后綴，完全可以自定義，參考這篇文檔：
searcher.ejlchina.com/guide/latest/params.html#字段參數
參數個數的多少，其實是和需求的復雜程度相關的。如果需求很簡單，那么很多參數沒必要讓前端傳，后端直接塞進去就好。比如：name 只要求后模糊匹配，age 只要求區間匹配，則可以：
這樣前端就不用傳 name-op 與 age-op 這兩個參數了。
其實還有一種更簡單的方法，那就是 運算符約束（當約束存在時，運算符默認就是 onlyOn 屬性中指定的第一個值，前端可以省略不傳）：
@SearchBean(tables="user?u,?role?r",?joinCond="u.role_id?=?r.id",?autoMapTo="u")? public?class?User?{@DbField(onlyOn?=?Operator.StartWith)private?String?name;@DbField(onlyOn?=?Operator.Between)private?String?age;//?為減少篇幅，省略其它字段... }入參是 request，我 swagger 文檔不好渲染了呀
其實，Bean Searcher 的檢索器只是需要一個 Map<String, Object> 類型的參數，至于這個參數是怎么來的，和 Bean Searcher 并沒有直接關系。前文之所以從 request 里取，只是因為這樣代碼看起來簡潔，如果你喜歡聲明參數，完全可以把代碼寫成這樣：
@GetMapping("/index") public?SearchResult<Map<String,?Object>>?index(Integer?page,?Integer?size,?String?sort,?String?order,?String?name,?Integer?roleId,@RequestParam(value?=?"name-op",?required?=?false)?String?name_op,@RequestParam(value?=?"name-ic",?required?=?false)?Boolean?name_ic,@RequestParam(value?=?"age-0",?required?=?false)?Integer?age_0,@RequestParam(value?=?"age-1",?required?=?false)?Integer?age_1,@RequestParam(value?=?"age-op",?required?=?false)?String?age_op)?{Map<String,?Object>?params?=?MapUtils.builder().field(Employee::getName,?name).op(name_op).ic(name_ic).field(Employee::getAge,?age_0,?age_1).op(age_op).field(Employee::getRoleId,?roleId).orderBy(sort,?order).page(page,?size).build();return?mapSearcher.search(User.class,?params); }結語
本文介紹了 Bean Searcher 在復雜列表檢索領域的超強能力。它之所以可以極大提高這類需求的研發效率，根本上歸功于它 獨創 的 動態字段運算符 與 多表映射機制，這是傳統 ORM 框架所沒有的。但由于篇幅所限，它的特性本文不能盡述，比如它還：
支持 聚合查詢
支持 Select|Where|From子查詢
支持 實體類嵌入參數
支持 字段轉換器
支持 Sql 攔截器
支持 多數據源
支持 自定義注解
等等
項目 GitHub 地址
https://github.com/ejlchina/bean-searcher
來源：juejin.cn/post/7027733039299952676
推薦文章1、一款高顏值的 SpringBoot+JPA 博客項目2、超優 Vue+Element+Spring 中后端解決方案3、推薦幾個支付項目！4、推薦一個 Java 企業信息化系統5、一款基于 Spring Boot 的現代化社區（論壇/問答/社交網絡/博客）總結
以上是生活随笔為你收集整理的我这样写代码，比直接使用 MyBatis 效率提高了 100 倍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 都在建议你不要直接使用 @Async 注
- 下一篇： 快手二面：引入RabbitMQ后，你如何