今天跟大家分享2个小点:
【1】在写Get请求时(使用SpringBoot),多传入参数的2种处理方式。
【2】如何配合‘@Select’关键字,写一个动态可拼装的Sql语句。(动态Sql)
下面我们来一个一个说
【1】「在写Get请求时,多传入参数的2种处理方式」
方案一:
@GetMapping(“abc/{x}/{xx}/{xxx}”)
public Map<String, Object> getXXX(
@PathVariable String x,
@PathVariable String xx,
@PathVariable String xxx) { return …}
该方案请求接口时,api_url为:
http://………………/abc/x/xx/xxx
方案二:
@GetMapping(“abc”)
public Map<String, Object> getxxx(HttpServletRequest request){
String x = request.getParameter(“x”);
String xx = request.getParameter(“xx”);
String xxx = request.getParameter(“xxx”);
…….
return …
}
该方案请求接口时,api_url为:
http://………………/abc&x?xx?xxx
ps.还记得之前分享过的一个原则嘛?「不要相信前端传过来的数据」
即:「尽量要前端少传递数据,对于前端传过来的任何数据,都要先做校验操作,校验通过后,再对其进行相关处理来使用该数据。」
所以可以在上述方法体内,做一些参数的校验判断,比如:
if (x == null || x.isEmpty() ) {…} //等其他方式,来做校验操作
【2】「如何配合‘@Select’关键字,写一个动态可拼装的Sql语句」
用过‘@Select’关键字(MyBatis)来写过sql的同学,应该都遇过一种情况:
默认一般的‘@Select’写法是:
比如:
@Select(“select * from xxx where x = #{x} and x_x = #{xx} and x_xx = #{xxx}”)
public List<xxx> getxxx(
@Param(“x”) int x,
@Param(“xx”) int xx,
@Param(“xxx”) Date xxx);
这样写,
好处是,直接了当。
坏处是,sql语句只能一次过,不能动态拼接。
当需要针对选择判断结果,来动态拼接sql时,就会很不方便。
因为该dao是interface,不是class。如:
public interface XxxDao{}
所以,
public List<xxx> getxxx()
只能声明,不能实现
那么,但我们有「需要针对选择判断结果,来动态拼接sql」这样一个需求时,应该怎么办呢?
可以这样写:
比如:
@Mapper
public interface XxxDao {
@SelectProvider(type = XxxDaoProvider.class, method = "getxxx")
public List<xxx> getxxx(
@Param(“x”) int x,
@Param(“xx”) int xx,
@Param(“xxx”) Date xxx);
class XxxDaoProvider {
public String getxxx(
@Param(“x”) int x,
@Param(“xx”) int xx,
@Param(“xxx”) Date xxx) {
String sql = “Select …….”; //sql语句
if(x != null ){
sql += "and x = #{x}";
}
return sql;
}
}
这样写,
就可以实现:
需要针对选择判断结果,来动态拼接sql
比如上例,根据:
*下面这一条件判断,来决定:。
if(x != null ){}
这条sql,是否需要多拼接上,下面这个筛选条件:
sql += "and x = #{x}";
PS.上面sql中出现的#{},说明一下:
@Select(“Select * from x where xx = #{xx}”)
//xx变量会被自动加上「‘’」—> where xx = ‘xx’,从而可以防止sql语句被外部注入,提升了数据库操作的安全性。
@Select(“Select * from x where xx = ${xx}”)
//xx变量,不会,被自动加上「‘’」—> where xx = xx,即,直接把xx变量的值,拼接到sql上,所以无法可以防止sql语句被外部注入,会降低数据库操作的安全性。
—— zeroOS 复盘于 2018/05/17
「zeroOS·简书号」
© 著作权归作者所有
网友评论