cms查询系统(一)背景以及需求分析与设计

原创
2015/03/26 06:55
阅读数 1.8K

本人想做一个cms查询框架,用于解决实际的业务问题,顺便锻炼下能力 #1 背景介绍

在一个配置管理系统即cms系统中,有很多的实体,实体间有很多的关联关系,这些实体就是构建成了一张网。如下图所示: 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"
	}
}
展开阅读全文
加载中

作者的其它热门文章

打赏
3
3 收藏
分享
打赏
1 评论
3 收藏
3
分享
返回顶部
顶部