同一套员工请假数据，需要同时支撑两个完全不同的业务入口。员工进入系统以后，只关心自己的请假申请、起止日期、请假类型和当前审批状态。主管进入审批应用以后，看到的却应该是员工姓名、组织信息、请假天数、审批状态以及批准和拒绝操作。如果按照传统 CRUD 应用的思路处理，很容易为员工端做一套数据模型，再为审批端复制一套数据模型。两边的数据来源其实完全一样，却逐渐演变成两套 CDS、两套业务逻辑甚至两套维护规则。在 RAP 里，更合适的设计不是复制 Business Object，而是让同一个 RAP BO 面向不同服务形成不同的 projection。CDS transactional query就出现在这里。SAP 对它的定义非常明确。Transactional Query 是一种 CDS Projection View，用于在 ABAP RESTful Application Programming Model，也就是 RAP 中，把通用 CDS 数据模型调整成某个特定服务需要的形态。它允许服务层进行数据裁剪、字段重命名、适度的反规范化，并承载不应该进入通用数据模型的服务级细节，例如 UI annotation、value help、计算以及 defaulting。如果把 RAP 应用按照职责拆开来看，我通常会把它理解成几层。最下面是持久化数据。往上一层是 CDS 数据模型。再往上一层是 RAP Business Object，它定义实体结构以及 create、update、delete、action、validation、determination、locking、authorization 等事务行