首页
App
&
Coffee
文档
项目
分享
反馈
俱乐部
登录
注册
为什么不加入更多的通用查询?
wuwz
2017-01-03 13:23
比如:findAll(), findFirst(searchEntity) 等等,
目前自己也可以实现,只不过要自行实现代码生成器,在BaseModel中加入相关的通用查询
项目:
JFinal
评论区
JFinal
2017-01-03 15:31
在多数情况下,findAll() 这种方式不是 jfinal 提倡使用的 api,jfinal 提倡 select 具体的字段,可以养成更好的习惯,而且无条件查询表中所有数据的情况并不是经常发生,即便有这种需求,也可以通过 find("select * from t") 来实现,这种实现方式不仅代码量并没有提升,而且开发者自己明确自己是否真的需要无条件 select * 查询当前表中所有数据
而对于 findFrist(searchEntity) ,jfinal 并不是很容易地确定该怎么去利用 searchEntity 中的查询条件,例如:是利用其中的所有条件? 还是利用部分条件? 是某个条件用 and 还是某些条件用 or 和 not?还是用 not exists 和 in?
查询条件的多少与利用方式是一个极其个性化、业务化的事情,如果 jfinal 去插手这个事情,事情可能变得更糟糕,并且更加复杂。所以对于这个问题,jfinal 是开放 String sql 与 Object... sql,这两个参数来让用户自由去发挥,无招往往才是最好的招
当然,为了方便用户更加方便和灵活的定制 sql,目前的 jfinal 版本还做得不够,这正是即将推出的 jfinal 新版本要做的事情,多多关注社区动态,近期发布新版本
回复
wuwz
2017-01-05 14:23
@JFinal
嗯,波总说得很有道理,那就期待新版的发布了!
回复
发送
我要反馈
热门反馈
扫码入社
而对于 findFrist(searchEntity) ,jfinal 并不是很容易地确定该怎么去利用 searchEntity 中的查询条件,例如:是利用其中的所有条件? 还是利用部分条件? 是某个条件用 and 还是某些条件用 or 和 not?还是用 not exists 和 in?
查询条件的多少与利用方式是一个极其个性化、业务化的事情,如果 jfinal 去插手这个事情,事情可能变得更糟糕,并且更加复杂。所以对于这个问题,jfinal 是开放 String sql 与 Object... sql,这两个参数来让用户自由去发挥,无招往往才是最好的招
当然,为了方便用户更加方便和灵活的定制 sql,目前的 jfinal 版本还做得不够,这正是即将推出的 jfinal 新版本要做的事情,多多关注社区动态,近期发布新版本