思考与总结01: 关于MyBatis 以及 业务接口的编写

xml:

select * from temp_table
where 
<if test="list != null and list.size() > 0" >
	b.`dept` in
	<foreach collection="list" index="index" item="item" open="(" separator="," close=")">
	#{item}
	</foreach>
</if>

通过 if 判断你的list是否为空(备注:这里 != null 是不够的，还要加入size来判空)
同时使用foreach来对每个值进行插入

调用的函数名称:

ReturyType method(@Param("list")List<Integer> list);

通过 @Param来指定你的参数对象

备注：同一个查询语句其实可以满足多个不同条件的查询，在xml中可以多使用 if 条件来判空，这样就可以通过这种条件来实现代码复用

---

####关于如何编写枯燥的业务接口(查询等)的一些构想

最近一段时间实现了很多业务代码，主要是集群使用信息、耗费之类的要求展示的前端页面上。因此对于后端这边而言需要实现很多查询。
数据在数据库中存储的时候需要遵循数据库范式，这样的表就很少冗余字段。对于查询的时候，需要描写一些多表关联的查询语句。
通常上，mapper当中复查查询的带来的结果是这样的:

1. mapper类过于繁重和复杂，冗余了很多单调的、复杂的查询语句。
   不利于代码阅读，不利于问题排查,也容易出错，如果这时候再缺少必要的文档，那么对其他人而言就必须说是一种灾难…
2. 对于后续的开发而言，如果涉及到前端改动(展示信息的修改 etc.)，或者是后端的数据库改动，字段修改等等。就必须要对mapper、controller、service进行一次联动修改
   那么这种代码就违反了设计模式当中的OCP原则。这样的代码僵化腐臭…相当的恶心(对不起，我写了不少这种代码，喂大家吃屎了)。

在阅读《敏捷开发》后，总结自己的代码，发现开发人员在设计实现的时候就必须要对后续可能的变化做需求统计，或者说设计尽量涵盖可能发生的不同变动(但是，
这一段耗费的时间和精力是很大的，通常情况我们不能做到这一点)。

扯远了。
#####如何解决这种僵化的设计？
最好的办法是：推掉这个需求给别人做(但是这个基本不可能)。

在观望了其他组件的对应项目实现:
Grafana(集群服务器状态信息监控服务)，这类服务组件通常上打开一个网页都是几十上百的的查询请求。在这种情况下去一一编写对应的接口明显是不切实际的。
一个优秀的解决方案是： 把SQL交付给前端。
举个例子:

http://url?db=dbItem&query=selectQuery

后端只需要把，数据库名，查询语句模版交给前端。那么，查什么样的数据，时间范围，或者是一些过滤条件都由前端来掌控。
这个时候，在服务端只需要一个接口就可以解决所有的查询(不用担心并发量)。
这么做的好处：

1. 易读，好维护。对于后端而言，就仅仅实现一个接口，不需要在mapper、service当中大做文章。对于出错的情况，打印一个log就可以很好的定位问题所在。另外，
   不需要额外的开销。开发仅仅需要考虑的是如何避免SQL注入的威胁(这里推荐一个轻量级的SQL解析工具 JSQLPaser)
2. 易拓展，也方便修改。 emmmm,这里肯定让人矛盾，实际上一个服务不应该是对拓展&修改开放的。但是，对于新增的某些业务查询接口而言，我们仅仅只需要提供的是SQL查询。
   对于相应的变动，也是需要修改查询语句，而不需要对接口进行修改。