做过 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
