关于实际项目中 UI 选项的思考：到底用不用 SAP Fiori？

在多年 SAP 开发与架构实践中，我发现有个有趣的现象：我曾经刻意跳过 Fiori，并且现在当回望当时的经历，依旧觉得这是一个明智的选择。本文将从多个角度解剖这种决定背后的逻辑、实际案例，以及对技术架构和业务需求的启示。

Fiori 并非总是首选

当我在项目中遇到 SAP 前端 UI 的需求时，我并没有第一时间想到 Fiori。理性地说，这并不是因为我对 Fiori 本身有偏见，而是因为架构师的核心职责之一，就是在技术选型上做到“最合适的工具”，并不是简单选用最流行的解决方案。

尽管 SAP 大力推广 Fiori，但项目环境千差万别。我发现有时候，直接用 SAPGUI、WebDynpro、Adobe Forms、甚至经典的 SAPscript，反而能更快速、更低成本地满足业务需求——尤其是当业务流程相对固定、性能要求高、用户培训成本重要以及现有系统高度定制。

跳过 Fiori 的考量

以下是我在项目中跳过 Fiori 时反复思考的几个关键点：

项目已有可用流程，效率优先

我曾结合 Adobe Forms 实现一个更精细的 PDF 渲染与打印需求，当时客户端的业务流程是文档生成和打印最为核心。而 Fiori 的 HTML5 渲染方式在打印方面相对复杂；与之相比，Adobe Forms 不仅熟悉，而且性能稳定、交付效率高，也无需额外培训。

成本节省与项目节奏控制

Fiori 的上线涉及前端资源、UI5 库、测试设备、