11.1 工作单元

为什么 11.1 工作单元 值得单独学习

先想象一次订单结算：页面让订单、客户和库存连续发生变化，最后却只成功写入其中一部分。读者看到的可能只是一个错误提示，但系统已经留下了无法解释的半成品。这个章节要解决的就是“谁负责把一组相关变化一起送达”的问题。

没有这样的统一边界，每个对象都可能在自己的时刻保存，调用者也无法知道哪些变化已经落地。结果是重试会重复写入，失败会留下脏数据，审核日志又很难还原当时到底写了什么。

本页以 2024 年中文版公开目录限定 11.1 工作单元 的范围，并依据 Martin Fowler 的作者图书页和模式目录独立重写。它不复现原书正文、插图或代码；目录只决定“要讲什么”，这里的案例、实验、判断题和答案均为本课程原创。

先建立直觉：把一笔业务装进同一个信封

先猜一猜：如果订单已经写入，但客户积分更新失败，系统应该把订单留下，还是让整次结算回到开始前？答案取决于是否存在一个能看见整组变化、最后一次性裁决结果的边界。

这个边界像一个待寄出的信封：业务代码先把要新增、要修改和要删除的内容放进去，过程中可以继续检查规则；只有在信封封口时，所有内容才一起交给存储系统。信封没有封好，就不应把其中一张纸单独寄走。

核心概念：从变化集合到一次提交

什么是工作单元

是围绕一次业务操作建立的暂存边界。它不代替领域对象作业务决定，而是记录哪些对象将被持久化、怎样排序、何时提交，以及失败时怎样回退。这样，调用者不必在每个对象旁边重复编排保存顺序。

它的最小接口通常包含三个登记动作和一个提交动作：登记新对象、登记已修改对象、登记待删除对象，最后执行 commit()。登记动作只改变内存中的待写集合；提交动作才打开写入阶段。把这两个阶段分开，才能在提交前检查重复身份、缺失关联和版本冲突。

变更登记不是自动侦测

是工作单元能够可靠工作的前提。显式登记适合边界清楚的代码：registerNew(order) 表示插入，registerDirty(customer) 表示更新，registerRemoved(oldItem) 表示删除。若框架选择自动侦测，也必须能解释它如何发现对象变化，以及发现失败时怎样报警。

三个集合不只是实现细节，它们表达了写入意图。新增对象通常要先获得身份，修改对象需要确认版本，删除对象要处理被其他记录引用的关系。把三类变化混在一个“待保存列表”里，会让顺序和失败责任重新变得含糊。

原子提交与失败边界

把提交阶段变成一个不可分割的结果：全部写入成功，或全部回滚。它依赖底层事务能力，但工作单元仍然负责把对象变化组织成一个可执行计划，并在错误处停止后续写入。

“原子”不等于“永远不会失败”。数据库约束、网络断开、版本检查或外部服务都可能让提交失败；模式的价值在于失败发生时，调用者仍能知道哪些变化属于同一组，并能让存储层回到提交前的状态。若底层不支持回滚，就必须把限制写进选择记录，而不能假装工作单元已经提供了原子性。

生命周期中的三个协作者

身份映射让同一对象只出现一次

解决的是对象访问的一致性，而不是提交顺序。一次结算中，如果订单被加载两次，工作单元应当看到同一个对象引用；否则第一次修改可能落在一个实例上，第二次登记却把另一个实例当成最新状态。

身份映射通常与工作单元共享生命周期：工作单元开始时建立，工作单元结束时清理。它可以减少重复查询，却不能替代变更登记，也不能把它升级成跨请求的永久缓存。缓存范围越大，过时数据和并发判断越难解释。

并发冲突需要在提交前有答案

常见于两个请求同时修改同一订单。工作单元可以在对象上保存版本号，在提交时把“读取到的版本”作为更新条件；条件不满足，就拒绝本次提交并回滚，而不是默默覆盖另一个请求的结果。

因此，工作单元的边界至少要回答四个问题：谁拥有待写集合，谁决定顺序，谁触发回滚，谁向调用者报告冲突。若这些答案分散在 ORM 回调、控制器和数据库触发器里，表面上仍有一个 commit()，实际却没有可审计的责任链。

用订单聚合走一遍五个阶段

把订单聚合持久化切成“事务范围 → 身份映射 → 对象访问 → 变更集合 → 提交”五个观察点。每个阶段都要能指出输入、输出和失败信号：范围结束意味着登记关闭，身份映射保证同一对象，访问阶段产生领域变化，集合阶段形成写入计划，提交阶段才与数据库交互。

const uow = new UnitOfWork();
const order = await orders.load(orderId);
order.addLine(line);
uow.registerDirty(order);
uow.registerNew(invoice);
await uow.commit();

这段代码的关键不在类名，而在责任顺序：领域对象先产生变化，工作单元再登记变化，最后由一次提交统一执行。若 load 返回的对象没有纳入当前范围，或 commit 内部仍然逐对象自动保存，代码看似简洁，实际已经绕过了模式的边界。

三步交互实验：观察登记与提交

下面的分步图把同一笔订单从登记到提交的状态变化拆开。先预测：把第三步的提交顺序改成“更新客户 → 插入订单 → 删除旧条目”，当订单身份尚未建立或某一步失败时，会比图中的顺序更安全吗？用每一步的图示检查你的答案，再用练习中的代码修改题复现它。

常见误区

选择与拒绝矩阵

本章小结

• 工作单元收集一次业务操作中的新增、修改和删除。
• 变更登记表达写入意图，原子提交表达整组成功或回滚。
• 身份映射保证范围内的同一身份只对应一个对象。
• 并发冲突应在提交时被拒绝、回滚并报告，而不是静默覆盖。
• 只有当范围、顺序、失败和替代方案都可审计时，才值得采用该模式。

本章练习

const uow = new UnitOfWork();
const order = await orders.load(orderId);
order.addLine(line);
uow.registerDirty(order);
await uow.commit();

const customer = await customers.load(order.customerId);
customer.addPoints(line.points);
uow.registerDirty(customer);
await uow.commit();

名词解释

出处声明

前后导航

• 上一页：第11章 对象-关系行为模式
• 下一页：11.2 标识映射