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重來的狀況。

 

本文爲欣欣念念原創並首發於博客園，轉載請註明出處。