共计 5054 个字符，预计需要花费 13 分钟才能阅读完成。
什么是前端数据建模？
提到数据建模，大多数人第一工夫想到的都是和后端、数据这些方面相干的内容。而前端数据建模，仿佛让人感到生疏。
那么我通过答复上面几个问题，来对立一下咱们对前端数据建模概念的了解。
什么是数据建模？
数据建模是对业务逻辑所应用的数据以及这些数据之间的关系进行剖析和定义的过程。
数据建模有何意义？
- 为团队成员之间的合作创立一种对立的模式。
- 通过定义数据需要和应用状况来发现改良业务流程的机会。
- 节俭代码保护老本。
- 缩小谬误，改良数据完整性。
前端有必要进行数据建模吗？
在我的理念里，前端应该始终以用户体验为外围。然而事实上，前端无奈齐全脱离业务逻辑。那既然波及到业务，那就应该构建模型。
前端数据建模有何优缺点？
研发阶段：须要破费工夫和精力进行数据和关系的定义。
维护阶段：节俭逻辑变更后的批改工夫，让页面放弃绝对稳固。
综上所述，在业务逻辑绝对简单的零碎中，前端数据建模是很有必要的。而在一些临时性的我的项目中，则没有必要进行数据建模。
页面与模型
数据建模，就是围绕数据建设一个模型。
在大多数前端研发人员眼里，通常都会以页面（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 来实现的。路由是页面的一部分，不可复用。剩下的接口、数据和业务逻辑，都是在肯定水平上能够复用的。
而一个模型，次要是由数据和业务逻辑组成的。
数据建模该做什么？
目录构造划分
一个好的目录构造应该是高内聚、低耦合的。
很多人喜爱将文件夹依据技术职责进行辨别，如下：
这并不是我举荐的做法。我认为一个高内聚的目录构造应该是依据模块辨别的，如下：
文件夹的档次应该尽量扁平，而不是深层。
定义接口
定义接口的过程，基本上就是定义数据模型的过程。
因为接口是稳固的，而实现是易变的。
实现一个业务性能，轻易是一个程序员都能够做到，这并没有什么门槛。真正难的是如何对业务逻辑进行形象，定义成接口。这存在肯定门槛。
拿购物车这个场景举例。
购物车的数据分为如下几局部：
- 商品排序条件。
- 商品过滤条件。
- 图片显示状态。
- 商品列表加载状态。
- 购物车商品列表加载状态。
- 商品列表。
- 购物车商品列表。
- 商品总数。
- 商品总价。
扭转购物车数据的路径有如下几个操作：
- 初始化购物车。
- 增加商品到购物车。
- 在购物车删除商品。
- 减少商品。
- 缩小商品。
- 提交下单。
根据上述的文字定义，咱们能够利用 TypeScript 来定义出一个接口。
interface IGoodscartModel {
filter: Filter;
order: string;
imageVisible: boolean;
goodsList: GoodsList;
goodscartList: GoodscartList;
total: () => number;
quantity: () => number;
initialGoodsList: () => Promise<void>;
initialGoodscart:() => Promise<void>;
addToCart: (goodsId: string) => void;
plusGoods: (goodsId: string) => void;
minusGoods: (goodsId: string) => void;
removeGoods: (goodsId: string) => void;
submitOrder: () => Promise<void>;}一旦定义出这个接口，实现也就无关紧要了。因为业务逻辑的细节，轻易一个思维逻辑能力失常的人都能够写得进去。
对逻辑而言，接口就像是一张设计图纸。有了这张图纸，即便是最便宜的苦力一样能够建造出琼楼玉宇。
当然，其中有一些细节。
比方购物车商品总量和购物车商品总价，是通过计算而失去的，属于计算属性，所以在模型的定义中，将其定义为函数，而非根底类型。
比方初始化商品列表和购物车商品列表，是一种异步操作，所以定义为返回 Promise 的函数。
你可能会发现，这不就是面向对象编程中的常识吗？没错，这就是面向对象中的封装、继承、多态和组合。
辨别数据的性质
尽管在下面的模型中定义了很多个数据字段，但其实并不是所有的数据都肯定属于模型。有一些临时性的数据，是应该存储在页面中的。
辨别数据性质的办法有很多，但我认为，对前端而言并不需要适度简单，只须要依据一个条件来辨别即可 - 数据从何而来？
因而，能够辨别为零碎内部数据和零碎外部数据。
因为 Web 利用的特殊性，基本上所有的 Web 利用都依赖零碎内部数据。而这些数据通常都依赖接口提供。这种零碎内部数据绝对稳固和污浊。
而零碎外部数据，又能够依据业务的重要水平来辨别为多种类型。比方存储在内存中的值，能够称之为长期值。页面刷新时，这些值就会被重置。而重置的值，通常来自于两个地位，一个是存储在本地存储（WebStorage）中的值，能够称之为缓存值。另一个是写在代码中的值，能够称之为默认值。
这几类数据之间是存在流转关系的，也就是意味着不同性质的值，在零碎运行的不同阶段会互相转换。
比方页面加载时，先调用接口，获取零碎内部数据，获取胜利后，零碎内部数据转化为长期值，用户对长期值进行操作变更后，再对数据进行某种提交操作，将长期值同步到零碎内部。
用户的某些操作也能够将长期值存储到本地缓存，变成缓存值。
用户来到网站，再次回归时，会读取缓存值替换为长期值。
总结而言，数据的类型分为如下几类：
- 零碎内部数据（通常来自于接口）
- 零碎外部数据
- 默认值（通常硬编码在代码中）
- 长期值（通常存储在内存中）
- 缓存值（通常存储在本地缓存中）
这几类数据之间又能够互相同步与转换。
依据下面的归类，咱们能够发现，排序、过滤与图片显示暗藏状态应该归属于页面，而不是模块。
因为这些数据的性能是和页面强绑定的，或者说，这些性能自身就属于页面，不应该再割裂到模块中。
与框架联合实现数据响应式
数据模型的定义和框架并没有关系。但咱们通常须要配合数据响应式来实现操作数据自动更新 UI 的性能。否则就须要在模型中解决 UI 的变动，会导致模型依赖 UI，这不是咱们想要的。
目前最支流的 UI 框架，都具备数据的响应式。但我更举荐和一些状态治理库进行联合。
因为后面有提到，只有绝对有规模的我的项目才会用到数据建模。而在具备绝对规模的我的项目中，应用状态治理库能够让咱们的开发事倍功半。
上面是应用 pinia 的代码示例：
import {defineStore} from "pinia";
import {GoodscartModel} from "./model";
const goodscart = new GoodscartModel();
const {
goodsList,
goodscartList,
goodsListLoading,
total,
quantity,
initialGoodsList,
plusGoods,
minusGoods,
addToCart,
removeGoods,
order,
} = goodscart;
export const useGoodscartStore = defineStore("goodscart", {state() {
return {
goodscartList,
goodsList,
goodsListLoading,
};
},
actions: {
initialGoodsList,
plusGoods,
minusGoods,
addToCart,
removeGoods,
order,
},
getters: {
total,
quantity,
},
});减少接口的防腐层
定义模型，对前端而言还有另一层意义。就是能够起到隔离内部和外部的关联、进步零碎稳定性的作用。
咱们把前端想像成一个零碎，零碎中存在很多内部的资源，图片、视频、字体、图标、款式、脚本等等，以及十分重要的接口。
失常状况下，在开发过程中，接口中的字段名称、字段类型以及数据结构都是十分易变的，特地是遇到不业余或者对代码谋求较低的后端人员时，对接接口将会是一件十分令人感到懊恼和苦楚的事件。
从根本上看，造成这个景象的起因就是接口的变动不在咱们的掌控之中，它是零碎内部的不可控的事物。
那么该如何缩小和升高接口变动导致的前端变动呢？
答案很简略，减少防腐层。
防腐层 Anti Corruption Layer 是畛域驱动设计中的一个概念，用于隔离两个零碎，容许两个零碎之间在不晓得对方畛域常识的状况下进行集成。
次要进行的是两个零碎之间的模型（model）或者协定（protocol）的转换，并且最终目标是为了零碎使用者的不便而不是零碎提供者的不便，进一步的解释就是把零碎提供者的模型转换为零碎使用者的模型。
这个概念在前端落地到代码中非常简单，可能就是一个关系映射函数而已。
function dataMap(rawData) {
// ...logic
return formatData;
}当初，依照咱们上述实践构建的零碎中，是存在三个层级的，自下而上别离是防腐层、模型层和 UI 层，如图所示：
采纳这种形式构建的零碎，无论接口以何种形式返回数据、以何种数据格式返回数据，都不会间接对咱们的模型层代码进行毁坏，更不可能将这种破坏性穿透到 UI 层代码中。
当然，如果是整条业务流程都扭转了，那这种破坏性会影响到所有层级，这是不可避免的。
总结
前端数据建模是一种研发中大型规模我的项目和产品的可实际方法论，它通过设计一种模型来帮忙咱们升高零碎的复杂程度，这看上去很吸引人。
但咱们不能否定的是，从前后端拆散这种架构在业界真正风行开始（以 2016 年计算），距今曾经有六七年的工夫了，前端数据建模从未被对立或者被作为某种开发模式广泛应用。
那咱们不禁要思考了，前端数据建模到底是不是一件正确的事？
依据我的经验来看，有几个起因：
- 宏观业态：
- 前端程序员跳槽频率高。依据集体招聘经验和国内几个招聘大平台的数据来看，前端程序员的均匀跳槽频率有余 1 年。既然大家都是短工，那么为什么要思考那么久远的事件呢？代码被搞成了「屎山」，我跳槽便是，为什么要死磕呢？又不是找不到工作。
- 大多数公司不是特地器重前端品质。因为无论是大公司还是小公司，无论是传统行业还是互联网行业，都会更看重数据的重要性。因为网站只是展现数据、操作数据的一种伎俩。数据能力决定流程和金钱。甚至很多传统行业的公司，连 UI 都没有。只有中大型的互联网企业，才会有用户体验部门。既然公司都不器重，为什么要做呢？
- 宏观业态：
- 从业人员程度低。前端的门槛绝对较低，很多人还处于实现某个 UI 成果而抓耳挠腮的状态，哪还有什么精力投入到业务上来？流程跑不通？找后端哇。连问题都意识不到的人，怎么可能会去解决问题呢？
- 高手大多不屑于碰业务。编译构建、框架、组件化、数据可视化、WebGL、CI/CD、LowCode/NoCode、工具链 …… 前端能够深挖的方向太多太多了，但议论到谁技术好，基本上都是下面这些，很少有人会说，某人业务代码写得好，技术好牛啊。因为业务在大多数人眼里只是基本操作而已。再者，我后面也有说，前端的将来应该是交互和体验，而非业务。
但无论何种起因，都不能否定前端数据建模对业务的意义和价值。
时刻记住，咱们要成为工程师，而不是码农。