SAPUI5 freestyle vs SAP Fiori Elements —— 两种开发SAPUI5 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重来的状况。

 

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