应用数据模型？

o 是我在 18 年发布的一个工具库，用于快速创建数据模型，当时我写了一篇文章《Vmo 前端数据模型设计》得到过一段时间的关注，当时我从事三维装修相关的项目。在图形学的背景基础及海量复杂的数据的情况下，自然而然在前端则会衍生出一种数据处理、解析、消费的技术方案，也种下了我对数据模型概念的种子。

简单举个例子：需要解析一个三维装修的房子的数据会有哪些呢?

• 房子(Hourse),楼层(Layer),房间(Room),墙体(Wall),墙面(WallSpace),墙角(Corner),吊顶(Ceiling)，踢脚线(Skirting)，地(Floor，带厚度)，地面(FloorSpace)，门(Door)，窗(Window)。
• 以及会延伸出来大量的变体，比如飘窗，直角飘窗，弧形窗，墙洞，楼梯等等。

在解析这些数据中存在非常多的相互关联和计算，比如 房间需要和墙面，墙面需要和墙体关联，墙体和最多 2 个房间关联，墙角和多个房间关联，墙角和多个墙体关联等等

面对这样海量、复杂的数据，如果只靠着一个 API 请求的结果消费显然是非常不可取的方案，先不说这些数据能不能正确的解析出来，就说这些数据如何维护，保存时如何收集到所有数据反向序列化给后端都是些头疼的问题。

当然这些问题在当时我们抽象的各个数据模型中得到了解决，如果想了解具体细节可以查看我之前的文章。

今天我想讲的是，在我加入阿里后，一直在思考的关于数据模型的两个问题：

• 是不是数据模型这种事情对于常规项目没有使用场景或者价值呢?常规的，像一些数据查询，或者填写一些数据提交。这种需求里面有必要使用什么抽象类，什么数据模型吗?
• 为什么在前端圈子里面，很少有看到这方面的内容，现在前端圈子里大多都是在走向函数化，Composition等等，是不是这条路子走的有问题?

在寻觅了 2 年后，主导 Lazada 商家端的商品发布页面重构时，仿佛找到了一些答案。

二 商品模型

首先在新增一个商品的过程中，实际上是用户在以客户端的形式制作一组商品数据，常规的前端视角来看就是提交一份“JSON”。

而编辑就是通过 API 拉取这份“JSON”解析到 Form 表单中，让用户进行编辑后，再将这份“JSON”提交。

那么粗略的将数据抽象为模型将会成为这样：

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!