边缘计算场景下的增删改查与业务数据绑定实践

2. 从零手写增删改查：别把接口当CRUD

增删改查这四个动作，凡是写过两年代码的人都能列出来，但真正在业务系统里把它们做扎实，远不是“DAO层写四个方法”那么简单。我在接手这个“边-增删改查与业务数据绑定”项目时，最深的感受是：团队的同事早已会写增删改查，但业务数据绑定的思路普遍停留在“后端吐JSON、前端套表格”的层面，一旦涉及主子表联动、跨端状态同步、提交校验与回显一致性，就会频繁出问题。

这个项目实际要解决的是三件事：把边缘节点上采集到的数据做结构化存储，提供一套稳定可用的增删改查接口，再把接口返回的数据与前端业务表单、列表、详情页做双向绑定。“边”在这里可以理解成边缘计算场景中的服务节点，也可以理解为业务系统中的“末端操作端”——无论哪种，它都会带来同一种麻烦：网络不稳定、数据量不大但字段杂、并发写不高但对一致性敏感。

先说结论：如果只把增删改查做成“对着数据库写SQL再包一层HTTP”，那这个项目根本没有必要存在。它值得拆开来讲，是因为业务数据绑定层才是真正容易翻车的地方。

3. 业务数据绑定到底是什么

3.1 从“数据展示”到“数据契约”

很多人把数据绑定理解成“把后端字段塞进页面控件”，这是典型的误区。数据绑定的本质，是前后端之间建立一套数据契约，让用户的每一次操作都能准确映射为一条业务规则的变更。

举个例子：一个设备管理页面里，用户把“运行状态”从“在线”改成“维护中”。表面上这只是一次update操作，但业务上意味着：该设备对应的告警策略需要暂停、工单系统需要创建一条维护记录、设备所在区域的统计报表需要在下一个周期反映这个变化。如果绑定层只处理了“字段更新”，那这些连带业务就全部丢了。

所以业务数据绑定要考虑三个层次：

• 字段层绑定：控件和字段一一对应，解决展示问题。
• 实体层绑定：一组字段构成一个完整业务对象，解决提交与校验问题。
• 流程层绑定：业务对象的变化触发关联业务动作，解决联动问题。

很多项目做到了第一层就宣布“绑定完成”，后面两层的缺失会以隐性Bug的形式在测试后期集中爆发。

3.2 “边”场景下的绑定困境

“边”的场景给绑定增加了额外的复杂度。拿一个典型场景举例：车间里有多台边缘网关，每台网关管理着若干传感器，网络偶尔会断，网关本地会缓存数据。这时候如果业务人员在中控台修改了一个传感器的报警阈值，这个修改要先落到中控台数据库，再同步到边缘网关的本地库，最后在网关重启后仍然生效。

这个链路里，增删改查已经不是单纯的“数据库操作”，而是一个分布式数据一致性问题。前端表单提交的数据，经过接口层到达服务端，服务端写入主库，再通过消息或同步任务下发到边缘节点，边缘节点确认后返回结果。任何一个环节出问题，用户看到的就是“改了没生效”或者“改了又变回去”。

所以在设计阶段就要明确：业务数据绑定不只在浏览器里发生，它在客户端、服务端、边缘节点之间层层传递，每一层都要有绑定规则和异常兜底。

4. 项目整体设计与技术选型

4.1 为什么选择“前后端分离 + 边缘同步”架构

这个项目的整体架构，我从一开始就坚持前后端分离，同时把边缘节点的数据处理拆成独立模块，原因有三：

第一，业务数据绑定需要前端有完整的交互状态管理能力。服务端渲染或者传统MVC模式下，页面刷新就会导致绑定状态重建，很难做细粒度的脏数据检测和批量提交。前端分离之后，表单的状态可以独立维护，绑定关系也更清晰。

第二，边缘节点的网络环境决定了我们不能依赖“每次请求都实时连主库”的模型。必须要有一个本地存储 + 同步队列的机制，让边缘节点在断网时依然可以完成基本的增删改查，联网后再把变更推送到中心。

第三，团队后续要扩展移动端，前后端分离 + 接口化的数据访问方式是成本最低的路径。

这套架构你听起来可能觉得“不就是常规套路吗”，但真正落地时，边界划分的细节决定了项目的成败。我见过太多项目把“边缘同步”做成“定时全量拉取”，数据量小的时候看不出问题，一旦数据超过十万条，每次全量同步都会把带宽和数据库连接池打满。

4.2 技术栈与核心依赖选择

技术选型上，我最终确定的是这样一套组合：

• 前端：Vue 3 + TypeScript + Pinia，表单场景用 Ant Design Vue，表格用它的Pro版组件。
• 后端