SAPUI5 freestyle vs SAP Fiori Elements —— 两种开发SAP UI5 Apps的方式对比

概述

目前SAPUI5 SDK 提供了两种方式来开发一个SAPUI5 App。一种方式是传统的SAPUI5开发方式，一种是利用SAP Fiori Elements通过模板快速构建应用的方式。

本文简单介绍这两种方式如何实现，并进行对比，使读者更清楚这两种方式的优缺点以及适合的开发场景。

SAPUI5 SDK的官方网站在这里。我采用的开发工具是SAP Web IDE。

---

简介

SAPUI5 freestyle 就是SAPUI5 提供的最普通的最基本的开发方式，之所以给它起名字叫freestyle，就是为了区别于SAP Fiori Elements的开发方式。

freestyle方式的开发，前端由开发人员使用SAPUI5 API提供的控件自行编写所有页面View和前端逻辑Controller。自行通过OData Model进行数据绑定。自行通过编码的方式灵活的与后端进行交互。后端可采用SAP Gateway暴露Odata Service，在Runtime Artifacts中编写业务逻辑。

Fiori Elements方式的开发，前端只能选择SAP提供的Template模板生成特定样式的几种页面（模板数量在持续增加以支持更多样的业务）。这些页面基本满足SAP 自有的各种业务的需求。如果页面有特殊需求超出了模板提供的范围，可以利用template暴露的接口对模板进行扩展。后端一般采用CDS View自动生成Odata Service。并且通过CDS View生成的BOPF来实现业务逻辑。

不过前后端采用的技术并不是绑定的。freestyle的方式同样可以访问CDS View生成的Odata Service，只是不能利用BOPF的一些特性（目前来说）。Fiori Elements一样可以绑定到普通的SAP Gateway发布的Odata Service，但是要自己写OData Annotation来绑定数据和UI控件。

---

SAPUI5 freestyle App

详细的基于freestyle开发的基础教程在这里。

freestyle的开发，前后端逻辑分的比较清楚，基本无耦合。前端是典型的MVC框架。我们这里重点关注前端的实现。前端实现主要包括View，Controller和Model的实现。

基本步骤

1. 创建project。

2. 项目结构如下。

3. 项目的配置主要在manifest.json文件，组件的配置（model，router之类）在Component.js文件。

4. 在View中需要注意几点：配置controller控制页面逻辑，引入需要用到的lib的命名空间，使用model进行数据展示，注册事件触发controller逻辑。

5. Controller中，采用AMD的方式进行模块定义，并且注意利用onInit()，onExit()等7个基本方法，注意利用console.log()debug。

6. 前端可以自己mock数据，构建JSONModel进行测试，也可以配置OData数据源，通过OData JSONModel与后端进行数据交互。

7. 在SAP Gateway server上，使用T-code SEGW 进入SAP Gateway Service Builder界面，构建后端服务。关于后端OData Service的构建本文不做讨论。

8. 一个freestyle的project最简单也需要以上的操作。

---

SAP Fiori Elements

详细的基于Fiori Elements开发的基础教程在这里和这里（这个链接可能需要SAP内部员工权限）。

基于Fiori Elements的开发，前后端概念比较模糊，前端是模板化的，而模板的渲染需要很多后端注解的支持，前后端耦合较高，且对CDS View有一定要求。如果不使用CDS View和注解，就需要使用OData注解，我个人并不推荐这种方式。

我花了一个粗浅的个人理解架构图。

基本步骤

1. 创建CDS View。CDS View中既要包含你要展示的数据，也要包含这些数据关于UI的注解。这些注解将告诉UI Template的组件如何展示你的数据。关于UI的注解推荐采用annotation extension的方式实现。

@ODate.publish: true注解将自动生成OData Service。

2. 创建project。

这里的project类型选择SAP Fiori Elements。目前提供了五种，基本SAP的界面类型都包含了，还可以写自己的扩展。

创建project的时候需要选用第一步中发布的OData Service作为数据源。

3. 创建好的project就可以直接访问了，Fiori Elements会自动根据你CDS View中的UI注解去渲染和展示数据。

项目的目录结构如下。

4. 可以通过在本地覆盖external Annotations的方式来overwirte CDS View的UI注解。注意这里注解都已经转化成了OData Annotation。

5. 如有需要，可以增加自己的扩展。但是只能是在template暴露的API范围内。在manifest.json中配置扩展信息。

6. 一个Fiori Elements的project，最复杂的部分就是CDS View的实现，而前端只需要选择合适的Template，连接到数据源就好了。如果没有自己的样式调整和扩展，基本不需要任何代码工作。

---

关于Smart Control

Smart Control是一些能够根据注解自动生成完成很多工作的组件，比如用Smart Field根据注解能自动生成value help，Smart Filter Bar + Smart Table生成的带有Filter Bar的Data Table

能省去很多配置和编码工作就能展示后端数据，完成search，filter，sort等很多功能。使用SAP Fiori Elements的限制在于，Templates只有五种，并且里边的组件都是封装好的，我们能做的扩展也很有限。

如果在freestyle的project中，使用各种Smart Control控件配合注解，我们能享受到一些UI注解带来的方便，类似于Fiori Elements的局部快速构建。但是不知道出于何种原因，SAP不再推荐使用Smart Control，

虽然我们依然能使用，但是在SAP的一些文档中已经把Smart Control的使用方法部分删除了。

---

总结

这两种开发方式各有优缺点。

freestyle的方式，是典型的MVC架构，开发既需要懂JavaScript的前端工程师，也需要懂ABAP的后端工程师。

优点：

• 灵活，可配置
• 基于SAPUI5的强大组件库，基本能满足所有UI需求
• MVC架构，前后端分工明确，可并行开发

缺点：

• 同时需要前端和后端开发人员
• SAPUI5对于没接触过JavaScript的Abap开发人员来说，学习成本高
• 开发周期长
• 测试复杂

SAP Fiori Elements的方式，是SAP为了让ABAP开发人员能快速构建Fiori应用而开发的一种方式。

优点：

• 开发速度快且易于维护
• 在不同developer之间交接容易
• 前端几乎无代码和测试工作
• 测试简单。

缺点：

• 灵活性差
• 只能支持特定模板样式，扩展性差
• 对复杂的增删改支持较差

如果你开发的App比较简单，有SAP Fiori Elements对应的模板，并且项目上没有熟悉JavaScript的工程师，那么SAP Fiori ELements无疑是一个好的选择。

如果你要开发一个UI复杂，业务逻辑和UI交互逻辑都需要大量定制化的App，那么还是选择freestyle的更为保险。

总体来说，SAP公司的风格是喜欢把所有的东西都封装进ABAP的开发范围。不管是Webdynpro也好，SAP Fiori Elements也好，SAP都是希望工程师能在ABAP范围内就完成工作，只关注ABAP技术和业务逻辑即可。

这对ABAP工程师来说是一件好事。但是请注意，最好在项目一开始就对所有的页面有一个大概了解，并确定是否能采用SAP Fiori ELements，避免采用了Fiori Elements进行到一半突然发现有很多不支持的界面，

不得不推倒使用freestyle重来的情况。

本文为欣欣念念原创并首发于博客园，转载请注明出处。