简单封装了一个处理查询类请求的扩展包,各位大佬给提提意见(轻点喷)
最近挺闲的,就把自己一直使用的快速处理查询类请求的方法整理了一下,搞了一个扩展包。各位大佬给提提意见(轻点喷,我还是个孩子
)
废话不多说,先看效果

使用后可大大减少代码量!
开源地址:github.com/wyzheng1997/search-mode...,点点star
安装
composer require wyzheng/search-model
使用
目前支持的查询类型有:like、=、>、<、>=、<、!=、in、 between。
常规使用
// https://example.com/api/articles?title=test&category_id=5&created_at=2020-01-01,2021-01-02&user_id=1,2,3
$articles = Article::search([,
'title' => 'like', // 声明数据库title字段模糊搜索
'category_id' => '=', // 声明数据库category_id字段精确搜索
'created_at' => 'between' // 支持get数组参数或开始和结束用逗号隔开的形式
'user_id' => 'in' // 支持get数组参数或逗号隔开的形式
])->get();
自定义请求参数
当数据库字段和请求字段不同时,可以显式声明请求字段名
// https://example.com/api/articles?text=test&cate_id=5
$articles = Article::search([
'title' => ['like', 'text'],
'category_id' => ['=', 'cate_id'],
])->get();
跨表查询
当查询的字段是关联表的字段时,可以使用.的方式指定
// https://example.com/api/articles?title=test&author_name=jack
$articles = Article::search([
'title' => 'like',
// 当没有显式声明请求字段时,会自动拼接author_name
// 支持无限层级关联 author.company.name, 默认值 $request->input('author_company_name')
'author.name' => '=',
])->get();
自定义查询
可以通过自定义查询方法来实现更复杂的查询
// https://example.com/api/articles?title=test&type=1,2
$articles = Article::search([
'title' => 'like',
// $value = $request->input('type');
'type' => fn ($query, $value) => $query->whereNotIn('type', explode(',', $value)),
])->get();
预加载
search方法支持传入第二个参数(array),和原with使用方法一致,可以指定加载的字段
$articles = Article::search([
'title' => 'like',
], ['author' => function($author) {
$author->select('id', 'name');
}])->get();
查询排序
本扩展包还简单实现的查询排序功能sort
// https://example.com/api/articles?title=test&sort_by=asc(id),desc(author_level)
$articles = Article::search([
'title' => 'like',
])->sort(['id', 'author_level' => function($query, $direction) {
// $direction 取值 'asc' 或 'desc'
$query->orderByRaw('.......')
}])->get();
这个扩展只是想减少理想化场景下的代码量,对于复杂场景还是老老实实自己做(拒绝过度封装!),在项目中还是要根据情况适度使用。
题外话
一直听人说大环境不好,最近是真的感受到了,天天在公司没事干
,就想起来2016年就注册的公众号了,打算日更(纯写着玩,练习写作思维,也不知道能坚持多久),有兴趣的可以关注一下

本作品采用《CC 协议》,转载必须注明作者和本文链接
关于 LearnKu
浓浓的tp味
:+1:
设计目标上感觉有点像 packagist.org/packages/prettus/l5-... 这个项目的 Criteria。
但他们直接把条件进一步前置到请求里面了,如他给出的例子:
http://prettus.local/users?search=name:John;email:john@gmail.com&searchFields=name:like;email:=另外楼主是否考虑要将 聚合查询 和 显示字段 也通过请求数据引入进来?
感觉又引入了一套新的规则,有学习的成本。另外比如
'created_at' => 'between',这个和你其他规则设计不一致, 需要在脑袋里转个弯,甚至需要查看源码或文档。我觉得链式操作比这个好,起码我ctrl + q可以知道他这个方法需要哪些参数,你这个没有提示我还得照着文档写。
哈哈, 我之前也是直接数组一把梭实现的查询构建器,深度使用后发现场景一旦复杂就不好用不好维护。刚好这段时间给改成对象链式调用的版本。
"tucker-eric/eloquentfilter": "^3.1" 一直再用这个
不错,支持一下 :+1:
赞~!,之前我也是做了个和你类似的,但后面我又做了升级,在基类model用Builder::macro扩展了一个宏 ,根据字段类型匹配检索条件(如int=in,datetime=between,char=like等),无需配置检索字段与条件符,能满足80%的检索需求 ,也支持嵌套关系搜索。
接手的项目里就有这种,处理查询字段的,可以说是方便了自己,麻烦了后续的人.不过看你这还算简洁.我这个就懒得看他方法了,还是用一般写法