RAP Singleton Pattern 深度解析，一条技术根实例如何撑起整页编辑与表单录入

做过 SAP S/4HANA 业务配置类应用，很容易遇到一种和传统 CRUD 完全不同的页面需求。业务人员打开应用之后，并不希望先面对一个 List Report，再选择某条记录进入 Object Page。他们真正想看到的往往是一整张可以直接维护的配置表，或者是一张已经进入编辑状态的业务表单。这种需求看起来只是少一次页面跳转，真正落到 RAP 数据模型上，却会碰到一个很现实的问题。RAP Business Object 通常从 Root Entity 开始，SAP Fiori elements 也习惯把根实体理解成一组业务对象实例。List Report 展示多条 Root Entity，点击其中一条记录，再进入 Object Page，这条路线与 RAP 的普通事务模型非常契合。可配置维护页面不一样。我们的目标不是选择某一个业务对象，而是希望打开应用之后就进入一个固定工作区。这个工作区本身甚至没有多少业务意义，它只是负责把真正需要维护的数据组织到一个 Object Page 上，并承担锁、Draft、保存和导航入口等技术职责。这正是 RAP Singleton Pattern 很有价值的地方。SAP 当前 RAP 官方文档已经把这种模式用于 multi-inline-edit 场景。官方给出的设计思路也是建立一个只有唯一实例的技术 Root Entity，再通过 composition 挂载真正需要批量维护的业务实体。这个技术根实例成为整个页面唯一入口，同时承担 RAP lock master 所需要的角色。Singleton 在这里不要和 Java 设计模式里的 Singleton class 混为一谈。RAP Sing