在一个支持草稿编辑的 SAP Fiori 应用里，页面上看到的业务对象并不一定来自正式业务表。用户打开对象时，读取的可能是活动数据。进入编辑状态以后，同一个对象又可能切换到草稿持久化层。等到保存动作完成，草稿数据才会被激活并写回活动数据。单个实体的活动态与草稿态并不算难处理，真正容易出问题的是实体之间的关联导航。员工对象里有一条_manager关联，可以从员工跳转到经理。经理对象里又有一条_employees关联，可以查看这名经理管理的所有员工。活动数据阶段，两条关联都可以通过员工编号和经理编号完成连接。可是一旦进入草稿编辑，系统不能继续机械地依赖原来的业务编号，因为草稿记录拥有独立的技术标识，多个草稿实例甚至可能出现相同的语义键。此时，关联路径必须知道当前源实例处于活动态还是草稿态，也必须知道反方向导航该如何复用正方向关联已经建立的草稿映射。@ObjectModel.association.reverseAssociation正是为这一段导航关系提供信息的注解。SAP 官方文档把这种关系称为反向关联。两个节点之间已经存在一个方向的关联，而另一个方向交换了源实体和目标实体，同时仍然使用同一组连接元素表达相反方向的导航，这条关联就属于反向关联。反向关联不要求连接条件一定使用目标实体的主键，也经常表现为to-many基数。活动数据能够导航，并不代表草稿数据也能导航我们可以从员工与经理这个很常见的企业组织模型切入。员工实体拥有empl_id、first_nam
在一个支持草稿编辑的 SAP Fiori 应用里，页面上看到的业务对象并不一定来自正式业务表。用户打开对象时，读取的可能是活动数据。进入编辑状态以后，同一个对象又可能切换到草稿持久化层。等到保存动作完成，草稿数据才会被激活并写回活动数据。单个实体的活动态与草稿态并不算难处理，真正容易出问题的是实体之间的关联导航。员工对象里有一条_manager关联，可以从员工跳转到经理。经理对象里又有一条_employees关联，可以查看这名经理管理的所有员工。活动数据阶段，两条关联都可以通过员工编号和经理编号完成连接。可是一旦进入草稿编辑，系统不能继续机械地依赖原来的业务编号，因为草稿记录拥有独立的技术标识，多个草稿实例甚至可能出现相同的语义键。此时，关联路径必须知道当前源实例处于活动态还是草稿态，也必须知道反方向导航该如何复用正方向关联已经建立的草稿映射。@ObjectModel.association.reverseAssociation正是为这一段导航关系提供信息的注解。SAP 官方文档把这种关系称为反向关联。两个节点之间已经存在一个方向的关联，而另一个方向交换了源实体和目标实体，同时仍然使用同一组连接元素表达相反方向的导航，这条关联就属于反向关联。反向关联不要求连接条件一定使用目标实体的主键，也经常表现为to-many基数。活动数据能够导航，并不代表草稿数据也能导航我们可以从员工与经理这个很常见的企业组织模型切入。员工实体拥有empl_id、first_nam
