企业官网建设流程全解析

今天正在处理的ZExample_SalesOrder很有代表性。销售订单编号、客户公司名称、币种和含税总额都来自同一个 CDS 视图，可它们在业务人员眼里并不是四个毫无关系的字段。订单编号和客户名称属于订单的基本身份信息，币种和总额则属于销售金额信息。若把四个字段平铺在对象页上，数据当然能够显示，页面也未必报错，可阅读顺序会变得松散，表单很快就会像一张没有章节的纸质登记表。

@UI.fieldGroup正是为这种场景准备的。它不负责改变数据库结构，也不参与计算销售订单金额，而是在 CDS 元数据里描述哪些字段应当作为一组被消费。SAP Fiori elements 读取服务元数据后，可以据此构造表单式内容。SAP 对元数据驱动 UI 的描述也强调，CDS 注解提供默认 UI 模型，客户端在运行时读取这些元数据，实际界面还可能受到权限、个性化设置和运行环境影响。

这类设计的价值并不只在于少写几行 XML。更重要的一点，是业务语义开始进入可复用的服务元数据。销售订单的「常规信息」不再只是某个前端开发人员在页面里临时摆出来的两个输入框，而是被正式命名、排序并绑定到实体字段上的 UI 语义。相对于手工拼装表单，页面结构与后端模型之间少了一层容易漂移的重复配置。

一段代码里已经藏着两块业务表单

原始 CDS 定义如下，代码完整保留。

define view ZExample_SalesOrder as select from sepm_cds_sales_order as so { @UI.fieldGroup: [ { qualif