最近在梳理 SAP Fiori Elements 事务型应用时，一个很容易被低估的问题又冒了出来，我们在页面上填完字段，点保存，系统到底是在哪里判断这张单据能不能真正落库的。如果只是普通 Web 表单，很多团队会习惯把校验写在前端，字段为空就红框提示，金额不合法就弹 MessageToast，日期不合理就阻止按钮继续执行。可是到了 SAP Fiori 的业务语境里，这套做法远远不够。因为真正的业务对象并不是一个孤立页面，而是一个由 root node、child node、association、action、draft persistence、active persistence 共同组成的结构。一个销售订单的抬头看起来是几行字段，背后可能关联客户、币种、价格条件、行项目、审批状态和库存校验。UI 只能看到局部，BO runtime 才能看到完整事务。所以在 ABAP Programming Model for SAP Fiori 和 BOPF 体系里，validation 承担的不是简单的输入框校验，而是业务对象一致性的守门员。它关心的是，一个 active 或 draft 的 BO node instance 是否满足业务需求强加给它的一致性标准。只要这些标准不满足，系统就必须给消费端返回消息，必要时还要阻止保存，或者改变 draft 的一致性状态。说到这里，validation 的角色就清晰了，它不是为了让界面更好看，而是为了保证业务对象不会以错误状态进入持久层。Validation 不是修改数据的地方，而是判断数据是否可信的地方在 BOPF 的设计里，validation 只做一件事，检查当前节点实例是否一致。它不会替业务对象补字段
最近在梳理 SAP Fiori Elements 事务型应用时，一个很容易被低估的问题又冒了出来，我们在页面上填完字段，点保存，系统到底是在哪里判断这张单据能不能真正落库的。如果只是普通 Web 表单，很多团队会习惯把校验写在前端，字段为空就红框提示，金额不合法就弹 MessageToast，日期不合理就阻止按钮继续执行。可是到了 SAP Fiori 的业务语境里，这套做法远远不够。因为真正的业务对象并不是一个孤立页面，而是一个由 root node、child node、association、action、draft persistence、active persistence 共同组成的结构。一个销售订单的抬头看起来是几行字段，背后可能关联客户、币种、价格条件、行项目、审批状态和库存校验。UI 只能看到局部，BO runtime 才能看到完整事务。所以在 ABAP Programming Model for SAP Fiori 和 BOPF 体系里，validation 承担的不是简单的输入框校验，而是业务对象一致性的守门员。它关心的是，一个 active 或 draft 的 BO node instance 是否满足业务需求强加给它的一致性标准。只要这些标准不满足，系统就必须给消费端返回消息，必要时还要阻止保存，或者改变 draft 的一致性状态。说到这里，validation 的角色就清晰了，它不是为了让界面更好看，而是为了保证业务对象不会以错误状态进入持久层。Validation 不是修改数据的地方，而是判断数据是否可信的地方在 BOPF 的设计里，validation 只做一件事，检查当前节点实例是否一致。它不会替业务对象补字段
