本人想做一个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"}
}