本文已收录公众号(面汤放盐)：元数据思想-打破传统的思维方式

本文是一篇讲解元数据案例的技术文章; 同时也谈论如何对传统 CRUD 进行破局的文章。

元数据思想-打破传统的思维方式

打破传统的思维模式， 跳出固有的认知模型，从更高的视角去理解这个世界。

我将从案例进行逐步分析、讲解，一步步地打破固有模式； 感受一下从元数据的思维方式去解决传统的 CRUD。

一、构建查询案例--“看山是山，看水是水”

1.1 案例背景

下面是一个案例，该工具是帮助运维人员对公司的不同账号类型进行管理的后台。

比如下面是 T1 类型的账号， 通过输入 T1 类型账号，可以显示账号的数值列和操作列。 比如“打标” 是可以点击操作的操作列，员工ID只做展示的就叫数值列。

当然我也很难用一两句话让大家明白业务； 于是我简化业务，用更加技术的语言和图片来描述上面的功能场景。

T1 类型账号， 有3个数值列，2个操作列。

T2 类型账号：3个数值列，3个操作列

当然还有 T3、T4......不再赘述。

总结的规律：数据列和操作列是根据账号类型返回的， 列和值的数量是不同的。

一句话需求： 不同账号类型有不同的数值列和操作列。

那么，针对这样的需求，应该返回什么样的数据格式呢？接下来按照传统方式写一些 CRUD了。

1.2 传统思维模式-照着原型建模

于是会按照给定的原型进行数据建模，针对不同的账号类型返回不同的 VO 对象。

比如 T1 类型的账号 VO 返回体和数据实例如下：

[{
  "userId":"T1-001",
  "userName":"运维人员A",
  "isEnterprise":"是",
  "doFlag":"打标",
  "resetStatus":"重置状态" 
}]

并且和前端约定：doFlag 和 resetStatus 有值的时候，作为行为列。（告诉前端这个两个值要写死！）

同理 T2 类型的账号 VO 返回体，方式一样， T3、T4....... 如下所示：

传统开发模式： 拿着原型进行建模，就像上图一样，一一对应，好像没有什么难度。

打入这一行起，好像都是这么搞的，毫无问题。

这是一种传统的思维，甚至是一种僵化的思想。

1.3 劣势

这种按照原型建模开发的方式虽然非常简单，但是也存在一些弊端。

结合案例说劣势可能会更有体感。

 比如 T1类型和 T2类型，虽然很相似，但是一样需要有两套数据模型，甚至前端也需要写两套逻辑；类型越多，模型越多；

另外哪些列需要写成行为列，也需要固定写死； 

甚至当业务需求发生变化后，比如增加一个字段或者删除一个字段，从后端到前端，都要进行一一修改。

二、打破思维僵局--“看山不是山，看水不是水”

2.1 思维破局

既然传统方式有这么多不足，那么是否可以寻求一些变化，以此来破局呢？

再来回顾下面这张图（看这个世界的视角不同，解决方法也是不同的）

视角是会影响到思维的，因此可以从更高的视角来解决问题。 

进行传统功能开发的，就是按照一种较低的视角进行思维活动的。

如下所示：照着原型建模，谁不会呢？ 上半部分是原型，下半部分是模型； 就像那只在井里的蛙一样，看这个世界的方式总是抬头向上。

尝试站在更高的视角去看问题，尝试跳出固有的认知习惯，尝试以不一样的方式去理解这个需求。

于是提出一个想法：对表头行，数据行进行统一的建模。

1. 对表头进行分析，建模；对列值再进行分析建模。

2. 达成统一抽象

表头建模：

key：表示表头的唯一id值

title：表头需要展示值

type：表头对应的类型，type=action 表示这个列是行为列。

当然还可以对表头增加宽度、数值类型的元素，但考虑简单就忽略了。

列值建模：

key：与表头保持一致

value：表示具体值

对整个查询列表进行模型的重构，这样的模型具有更高的抽象维度，更具有普适性，扩展性。

所有的查询列表都按照上面的模式进行重构； 不管是 T1、T2、T3还是其他，都能使用同一模型进行表示。

对数据本身进行一种描述；从更高的视角进行抽象。

2.2 新的思维建模

那么返回的数据不再是固定模式的值了。对表头进行建模。三个字段如下：

对于数值列，这里比较简单，就用 key 和 value 就好了。类似 Map<Key,Value>

表头和数值列就如下所示：

数据案例如下：

{
	"headerList": [{
			"key": "userId",
			"title": "员工Id",
			"type": "display"
		},
		{
			"key": "userName",
			"title": "员工名称",
			"type": "display"
		},
		{
			"key": "isEnterpise",
			"title": "是否已是企业账号",
			"type": "display"
		},
		{
			"key": "doFlag",
			"title": "打标",
			"type": "action"
		},
		{
			"key": "resetStatus",
			"title": "重置迁移状态",
			"type": "action"
		}
	],
	"valueList": [{
		"isEnterpise": "是",
		"isWhiteList": "是",
		"userName": "运维人员A",
		"userId": "T1-001",
		"doFlag": "打标"
	}]
}

针对数据列，采用统一的接口。前端不用关心业务。

{{url}}/opsOperation?operationKey={{key}}&userId={{userId}}

通过 operationKey 作为后端路由值。比如打标的时候，operationKey = doFlag

通过这样的方式：所有的账号类型都可以采用统一数据模型。具有统一性、普适性、扩展性。

2.3 优势

1. 前端不用再关心业务，仅关注技术开发，不用涉及业务

2. 更能应对变化：比如可以将表头等信息放在分布式配置中心，这样可以动态新增调整，如后端可以动态控制列的个数、行为个数；当业务发生变化的时候，只后端进行调整，变更成本更低

3. 技术质量：代码重复度低，扩展性也更强

4. 当然也更有趣

虽然实现效果可能都是一样的，但实现的方式却千差万别；后续的维护成本也完全不同。

这是视角的不同，思维方式的不同， 同时也是一种抽象能力的不同。

三、一招鲜，吃遍天 --“看山还是山，看水还是水”

3.1 元数据思维

可以再来回顾一下这种图，可能现在会更有体感了。

元数据思维，从更高的视角去看问题；习惯跳出数据本身，而不是被数据本身所束缚。

只有跳出数据的泥潭，才能看清泥潭。“不识庐山真面目，只缘身在此山中。”

元数据是对数据本身的描述，层次更高！也是抽象维度、抽象粒度的不同。

可能你想问有什么秘诀吗？我可能会回答你，依葫芦画瓢地实践！这样你才会慢慢有体感！

关于抽象的文章，感兴趣可以阅读这两篇文章。

写代码这件事，迈入第七个年头才有了一些心得（第二章 抽象） - 掘金写代码这件事，迈入第七个年头才有了一些心得（第三章 抽象下篇） - 掘金

简单总结：

元数据：对数据进行描述。元数据的思想，尝试用更高抽象度定义数据；并跳出传统思维，用不一样的视角进行思维活动。 通过实践练习可以达到更好的效果。

3.2 更多案例

这种更高粒度的抽象案例其实还挺多的。也挺有意思的，对于 CRUD 传统思维的破局是一个非常不错的方式，简单再总结几个曾经做过的小案例。

案例一：表单类型的搜索

比如：搜索大于，小于，等于。

针对搜索控件进行建模，比如可以抽象建模：

1. 搜索方式

2. 搜索值

3. 数据类型

案例二：动态展示列

可以动态展示列。比如本案例中过，就可以根据前端勾选列，动态从后端去搜索多少列动态返回。

案例三：低代码

低代码台则更是抽象层次更高也更复杂，但是这种思维是能进行移植的。

其他的就不再一一赘述了。

3.3 最后感慨

编程的核心不是技巧，而是思维 ！

与其天天写一些没啥技术含量的东西，不如尝试变通一下！

与其坐而论道 不如起而行之！

最后再来回味一下这个图，希望有更多的想法和灵感！

欢迎关注微信公众号：面汤放盐(一个专注技术干货的博主)