本人想做一个cms查询框架，用于解决实际的业务问题，顺便锻炼下能力
1 背景介绍
在一个配置管理系统即cms系统中，有很多的实体，实体间有很多的关联关系，这些实体就是构建成了一张网。如下图所示： 
目前面临的问题是，如何轻松应对其他用户对实体的各种各样的查询需求？
2 需求整理
站在用户的角度来分析需求
2.1 用户的输入
2.1.1 用户要查询的数据
- 可能只需要获取某些想要的字段
- 可能想获取每个实体的所有字段
2.1.2 查询条件
- 各种各样的查询条件，如
如 =、 ！=、>、<、like、in、exists 等查询条件,时间段查询等 - 查询条件间的and or 关系，以及多层条件嵌套
如 a>2 and (b>3 or c<4)
2.2 查询输出
2.2.1 字段对应的值的格式化
如某个表的type字段的值为0或1,需要将这些0或1转化成有意义的值,如 0表示online 1表示offline
2.2.2 返回的数据形式的格式化
sql查询的结果是平铺的形式，然而返回给用户的希望是一个格式良好的形式，所以要求必须具备格式化的功能。
目前可能的格式化形式如下所示：
- 形式1 a下的所有的b（外层主体内容是a,然后包含一个b的集合）
{ "aName":"name1", "bs":[ { "bName":"name2" }, { "bName":"name3" } ] } - 形式2 b的信息(外层主体是b,然后包含一个a的信息)
{ "bName":"name2", "a":{ "aName":"name1" } } - 形式3 a下所有的b、c（外层主体是a,然后包含一个b的集合，也包含一个c的集合）
{ "aName":"name1", "bs":[ { "bName":"name2" }, { "bName":"name3" } ], "cs":[ { "cName":"name4" }, { "cName":"name5" } ] }
3 大概的设计
- 1 用户查询封装成QueryBody
- 2 对QueryBody进行解析，解析成sql
- 3 根据sql查询出对应的结果
- 4 对sql查询的结果进行值的格式化和形式的格式化，返回满意的结果
3.1 用户查询封装成QueryBody
QueryBody就是配置用户需求的地方。它的来源有两种方式，分别如下：
- 方式1 用户配置QueryBody的一些参数直接进行http请求
这种方式的情况下，用户需要了解QueryBody的配置意义，同时用户可以自行进行各种各样的查询
- 方式2 根据用户的查询需求，在后台配置QueryBody的参数，并映射对应的key,然后让用户拿着key来进行查询，如下
{ "key1":{QueryBody1的配置}, "key2":{QueryBody2的配置} }用户拿着key1来查询，即我们使用key1对应的QueryBody配置来进行查询。这种方式，用户不需要关心QueryBody的配置，但只能按照我们后台所配置的参数进行查询了。方式1就不需要维护信息，方式2就需要维护key对应的QueryBody的配置信息
以上的这两种方式都可能会出现，所以都要支持。
3.2 对QueryBody进行解析，解析成sql
这一部分其实就是一个sql生成器。这里需要说明的是，我们并不是去设计一个复杂的sql生成器，而是针对cms系统常见的查询操作能够生成sql就行了。所以不要指望这个查询框架能自动帮你生成复杂的sql。 但是有很多地方要注意：
3.2.1 对解析要进行缓存
方便下一次相同的请求直接跳过解析过程,加快搜索。然而一旦服务器关闭，缓存就消失，所以是否要考虑将解析缓存持久化起来，在服务器启动的时候，就去先加载解析缓存。
同时允许清空缓存等操作
3.2.2 普通查询sql的几个要素
普通sql如下所示：
select 表1.column_a,表1.column_b,表2.column_c,表3.column_d
from 表1 表2 表3
where 表1.column_e>4 and 表2.column_f='test'
主要分成三大部分：
- 第一部分 要查询的column
这一部分，可以让用户自己输入，还要进行下配置映射，避免对外暴漏数据库中的表和字段名
上述方式一般很少，所以大部分的时候还是，查询表1 表2 表3 的全部有用字段的信息，所以需要在后台配置哪些表的哪些字段需要对外暴漏。
上面的两种方式也都是要支持的
- 第二部分 表之间的连接关系
一种方式就是，直接配置表与表之间的连接关系（简单粗暴，但是会有很多的重复配置信息）
另一种方式就是，只配置两两表之间的连接关系，通过一个针对图的算法模块来找到表之间的连接关系。如博客开头的图片中，算法模块能够自动计算出entity1和entity4之间的连接关系是 entity1->entity2->entity3->entity4。这种方式大大减少了配置的冗余度。
虽然算法这一块是美好的，仍然会存在很多的问题。算法要找出最短路径，但是最短路径的连接关系不一定是用户想要的，所以有时候又不能来依靠算法，还需要人为的干预配置。如上图中的entity1到entity7有2条途径，算法只能给我们推荐一个最短的路径，但这并不一定是用户想要的，所以在这个时候，我们是需要配置使用哪条路径的
- 第三部分 查询参数部分
用户的查询条件就是一个json对象，我们要把这个json对象转化成sql中的where部分
用户的查询条件是各种各样的，同时查询条件是可以嵌套的，如下两种查询条件
{ "a.name":"lg", "b.age@>":24 }这里就表示查询 where a.name='lg' and b.age>24
{ "a.name":"lg", "$or":{ "b.age@>":24, "c.id@in":[1,2,3] } }这里就表示查询 where a.name='lg' and (b.age>24 or c.id in (1,2,3) )
所以希望能够做到上述的查询效果，这就需要设计一系列内置的查询参数解析器，同时方便用户自定义扩展查询参数解析器，来支持更加复杂的查询
3.3 根据sql查询出对应的结果
这一块就需要借助于如Spring的JdbcTemplate来执行相应的sql，或者借助于其他，这就需要思考如何更加方便的接入呢？
3.4 对sql查询的结果进行值的格式化和形式的格式化，返回满意的结果
sql的查询结果是平铺的，这时候就需要进行聚合操作，聚合操作就需要依据外层实体的主键作为聚合的重要依据了。
对数据进行格式化处理，就需要遍历查询结果，一一进行处理。然后返回给用户，如果用户还要进行相应的处理操作，又要遍历一次，造成浪费，所以该框架还要支持用户配置一些处理操作。
4 还涉及的问题
4.1 日志
- 该框架应该不能定死所使用的日志系统，所以需要采用slf4j这个统一的日志接口
- 对于程序中哪部分的日志采用debug级别，哪部分的日志采用info级别需要仔细考量。简单来说就是，程序的主要执行过程采用info级别，使得我们能够迅速定位错误原因就可以了，而一些详细的解析过程采用debug级别就够了。
4.2 配置文件的监控模块
为了不用重启服务器，就能方便的发布新的API、或者改动老的API，就需要对这些配置文件进行监控。
因为这些各种各样的配置文件会很多，所以就需要把监控单独写成一个模块，方便外界随意的添加监控项。
同时还需要监控的总开关和每个监控项的子开关，来随时关闭或者打开某个监控项。
4.3 上下文环境Context
在解析的过程中，用户的查询QueryBody，会在很多地方都要用到，如果都是作为方法的参数传递来传递去，将非常难看和难以维护，很明显这里就需要用到ThreadLocal形式了，将类似QueryBody和一些对应的缓存存储到绑定的对应的线程中，通过ThreadLocal对象来随时随地获取这些数据。最好是弄一个上下文环境来封装数据。
4.4 异常处理
配置文件加载、解析产生的异常要进行规范的自定义处理
4.5 集成与配置
如何更加方便的使用与配置这个cms查询框架
5 最终达成的效果
还是如文章最上面的图
1 用户输入如下：
{
"entites":["entity1","entity2s@listentity2","entity3s@listentity3"],
"params":{
这里放置查询参数
}
}
则代表查询的是所有的entity1，以及它所包含的entity2和entity3,返回的数据格式是如下形式的：
{
"entity1Name":"aaa",
"entity2s":[
{"entity2Name":"xxx"},
{"entity2Name":"xxx"}
],
"entity3s":[
{"entity3Name":"xxx"}
]
}
2 如果用户输入如下：
{
"entites":["entity2","entity1@mapentity1"],
"params":{
这里放置查询参数
}
}
则表示用户想查询entity2的信息，并且想知道每个entity2所属的entity1信息，是如下格式的：
{
"entity2Name":"aaa",
"entity1":{
"entity1Name":"xxx"
}
}