最近在梳理 SAP Gateway 的 Runtime Artifacts 时，有两个类很容易被放在一起看，却又很容易被低估，一个是ZCL_Project_Name_MPC，另一个是ZCL_Project_Name_MPC_EXT。在一个通过SEGW创建出来的经典 SAP Gateway OData 服务里，我们经常会把大量注意力放在DPC_EXT上，因为读取数据库、调用 BAPI、执行查询、处理新增修改删除，这些真正和业务数据打交道的代码，大多写在那里。时间久了，很容易形成一种错觉，似乎 OData 服务真正重要的只有 Data Provider Class。可是一个 OData 服务能够被 SAP UI5、Fiori Elements，甚至 Postman 正确理解，前提并不是先把数据读出来，而是先回答另外一个问题，这个服务到底长什么样。里面有哪些 Entity Type，有哪些 Entity Set，每个 Property 是字符串还是金额，哪个字段是 Key，哪些实体之间存在 Association，Navigation Property 指向哪里，哪些操作属于 Function Import。对于客户端而言，这些信息构成了整个服务的结构契约。负责定义这份契约的，正是 Model Provider Class，也就是我们平时看到的MPC和MPC_EXT。SAP 官方对 Model Provider 的定位非常直接，Model Provider 中包含用于在运行时定义 OData Service 数据模
最近在梳理 SAP Gateway 的 Runtime Artifacts 时，有两个类很容易被放在一起看，却又很容易被低估，一个是ZCL_Project_Name_MPC，另一个是ZCL_Project_Name_MPC_EXT。在一个通过SEGW创建出来的经典 SAP Gateway OData 服务里，我们经常会把大量注意力放在DPC_EXT上，因为读取数据库、调用 BAPI、执行查询、处理新增修改删除，这些真正和业务数据打交道的代码，大多写在那里。时间久了，很容易形成一种错觉，似乎 OData 服务真正重要的只有 Data Provider Class。可是一个 OData 服务能够被 SAP UI5、Fiori Elements，甚至 Postman 正确理解，前提并不是先把数据读出来，而是先回答另外一个问题，这个服务到底长什么样。里面有哪些 Entity Type，有哪些 Entity Set，每个 Property 是字符串还是金额，哪个字段是 Key，哪些实体之间存在 Association，Navigation Property 指向哪里，哪些操作属于 Function Import。对于客户端而言，这些信息构成了整个服务的结构契约。负责定义这份契约的，正是 Model Provider Class，也就是我们平时看到的MPC和MPC_EXT。SAP 官方对 Model Provider 的定位非常直接，Model Provider 中包含用于在运行时定义 OData Service 数据模
)
