写点什么

数据续谈

用户头像
顿晓
关注
发布于: 2021 年 05 月 15 日
数据续谈

RDB 的底层是 Records 和 Relations,在应用层则发展出了 SQL,代表一种比 OO 更简单的范式:

声明式描述,把 Rule/规则/逻辑组合以数据描述的方式展现出来,来代替 OO 繁杂的逻辑描述;

这种范式是 DSL,一种动态加载逻辑的方式,本质上是一种插件的实现方式。

但也有其缺点,不同 DSL 间无法兼容,有学习成本,难以复用,属 one piece of code;

优点也很明显,入门简单,可以没有编程基础,但深入时坑也多。


本着对复杂敬畏的态度,一般不自己轻易实现 DSL,但如果核心域的扩展/插件很多,可以提供简单的 DSL 以实现简单的需求,比如 CRUD;

不过由于 DSL 约束规范实在太少,以及全手写 SDL 也容易引人认为失误,对这些简单的 DSL 也封装了可编程接口 ORM,对此有如下几种理解:

1、ORM 在 SQL 基础上提供了 OO 抽象;

2、ORM 和 SQL 都是 RDB 提供的应用层接口;

3、SQL 时 RDB 和 ORM 之间的共同抽象依赖,解耦了 2 者。


从经典学习,因为其解决了当时的主要问题而成为经典;

所以学习经典不是直接拿来解决当前的问题,而是提供我们学习的素材,进而让我们练习分析问题、解决问题的能力;

熟读经典,让自己有压箱底的武器库。


举个例子,构建一个列表:

<lt>   <li/>  <li/>  <li/></lt>
复制代码


这是手写代码实现,最容易,但不是最简单,当业务逻辑增加时,复杂性可能超线性增长;


以上也可以说是过程式/命令式思维范式。

另一种是:

data=[  {lable: a, value: va},  {lable: b, value: vb},  {lable: c, value: vc},];  //数据面
<lt data={data} /> //控制面
复制代码


这就做了控制面和数据面的分离,也是当下最火的微服务的核心思想之一,暗合 DSL 范式;

其中控制面就是 RDB 的引擎,数据面就是业务通过 DSL 的直观表达;

也是软件演化所追求的方向--让业务逻辑能使用数据布局的方式来直观表达,这种方式比 OO 更简单,或者说这本不属于 OO 该做的事,OO 做的是控制面的事,数据面的事,还是有数据布局来做,DSL 是一种复杂的数据布局方式,但简单的结构体、json 更为常用。


回到集合

集合做为高级数据结构,用来描述更复杂的数据布局;

集合与逻辑之间的共同抽象依赖是迭代器,这让逻辑表达解耦了数据布局,摆脱了 RDB 强依赖导致的不能复用问题;

迭代器的各种操作函数 map,filter,reduce,就是数据处理 pipeline 抽象出来的 DSL,让工作流逻辑的表达相对直观。


消除重复做为代码设计最底层的驱动力,

逻辑有重复规律时,就提取数据组织新的布局,保存在集合中,让逻辑稳定下来;

数据有重复规律时,就用组织逻辑来自动生成数据,输出到集合。


逻辑和数据的表达,还有一种方式:IDL。

好处是简单,所以为一种语言实现也容易;

软件开发首要的是划分边界,IDL 就是划分边界的一种最佳实践。

后端服务间 rpc 一般都用 IDL 来定义协议,能快速把系统框架搭建出来。

一般的实现是序列化库+rpc,如 grpc,grpc-web 支持了浏览器端。


IDL 的难点,不在技术,在业务的需求分析,边界划分,数据建模。

大家使用 pbuf 时遇到的问题,也欢迎分享。


IDL 也会随着需求增加而逐渐变得复杂,如重复项需要提取出来;

还有就是接口依赖问题,导致需要请求多次;

最后是接口的版本管理;

GraphQL 针对这些问题做了改善,算增强版的 IDL。

发布于: 2021 年 05 月 15 日阅读数: 11
用户头像

顿晓

关注

因观黑白愕然悟,顿晓三百六十路。 2017.10.17 加入

视频号「编程日课」 知识星球「俺的死党顶」

评论

发布
暂无评论
数据续谈