在一个规模稍大的 SAP S/4HANA 数据模型里,经常会出现一种很熟悉的代码味道。同一套字段、同一套计算规则、同一组语义定义,在销售、采购、库存、财务分析等多个 CDS View Entity 中反复出现。刚开始只有两三个 View 时,复制几行代码似乎没有什么问题。等到系统演进了一两年,某个业务公式发生变化,开发人员才发现同一个公式已经散落在十几个 CDS 对象里,而且每个地方还存在一点细微差异。
CDS Aspect 要解决的正是这一类问题。
SAP 在新的 ABAP CDS 建模能力中引入 Aspect,并不是单纯为了少写几行代码。Aspect 更重要的价值,是把具有独立业务含义、能够跨多个 CDS Entity 复用的字段、计算表达式以及相关元数据集中起来,使其拥有独立于消费方 CDS Entity 的生命周期。SAP 官方文档把 Aspect 描述为一种提高模块化程度的建模机制,可将经常使用的字段、计算和相关 Metadata 集中定义,并在不同 CDS Entity 中重复利用。
这里最容易产生误解的地方,是定义好了 Aspect 以后,它并不会自动进入某个 View Entity。
从消费方 CDS 的角度看,需要完成两个不同动作。
一个动作是Binding。
另一个动作是Including。
这两个动作看起来很接近,实际上承担的是完全不同的职责。理解清楚它们之间的分工,基本就理解了 CDS Aspect 的使用模型。
假设已经存在一个 Aspect,其中某些元素或者计算需要依赖业务实体自己的字段。Aspect 自身只是可复用模板,它并不知道当前消费它的 CDS Ent