前端数据建模指南

什么是前端数据建模？

提到数据建模，大多数人第一时间想到的都是和后端、数据这些方面相关的内容。而前端数据建模，似乎让人感到陌生。

那么我通过回答下面几个问题，来统一一下我们对前端数据建模概念的理解。

什么是数据建模？

数据建模是对业务逻辑所使用的数据以及这些数据之间的关系进行分析和定义的过程。

数据建模有何意义？

• 为团队成员之间的协作创建一种统一的模式。
• 通过定义数据需求和使用情况来发现改进业务流程的机会。
• 节省代码维护成本。
• 减少错误，改进数据完整性。

前端有必要进行数据建模吗？

在我的理念里，前端应该始终以用户体验为核心。但是事实上，前端无法完全脱离业务逻辑。那既然涉及到业务，那就应该构建模型。

前端数据建模有何优缺点？

研发阶段：需要花费时间和精力进行数据和关系的定义。

维护阶段：节省逻辑变更后的修改时间，让页面保持相对稳定。

综上所述，在业务逻辑相对复杂的系统中，前端数据建模是很有必要的。而在一些临时性的项目中，则没有必要进行数据建模。

页面与模型

数据建模，就是围绕数据建立一个模型。

在大多数前端研发人员眼里，通常都会以页面（Page）为纬度来切割业务内容。而不会以模型（Model）为纬度来切割业务内容。这会导致一个问题，前端难以自己形成一个具有内聚力的系统。

和页面功能相关的内容都会存到该页面中。如果其他页面需要依赖这个页面中的某些数据或者某些功能，很多人会选择复制一份对应的代码来完成功能。因为这种做法趋近于人类的原始本能-「拒绝思考」。稍微有点追求的人，就会把多个页面中会共用的数据和函数提取到某个独立的位置，然后由这两个页面单独引用。这就是所谓的「封装」。但这种封装并没有逻辑性，它只是遵循了「多个页面引用了一个页面中的某个相同的功能，就要把这个功能抽离出去，封装成一个独立的函数」。这种做法并没有任何问题。但是，做的程度还是不够。

举个例子，在开发阶段，页面 Page A、B、C 都依赖了功能 Func X。于是你封装了 Func X。但是后面业务逻辑发生了变化，Page A、B 和 Page C 所需要处理的逻辑不同了。这时你要么在 Page C 中把对 Func X 的依赖全部移除，在 Page C 中写自己的逻辑。或者是在 Func X 中增加一段判断代码，将 Page C 和 Page A、B 进行区分，然后调用不同的逻辑。

无论哪种做法，在代码的维护上都不算简单。因为你的系统是完全不稳定的、是易变的。为什么会这样呢？是因为缺乏一个模型。

以目前的技术角度分析，一个前端页面，可以拆分为几个部分：UI、路由、接口、数据和业务逻辑。其中 UI 是纯前端层面的东西，复用是通过组件化或者 CSS 来实现的。路由是页面的一部分，不可复用。