Oracle APEX 系列文章6：Oracle APEX 到底適不適合企業環境？

本文是鋼哥的Oracle APEX系列文章中的第六篇，完整 Oracle APEX 系列文章以下：

• Oracle APEX 系列文章1：Oracle APEX, 讓你秒變全棧開發的黑科技
• Oracle APEX 系列文章2：在阿里雲上打造屬於你本身的APEX完整開發環境 (準備工做)
• Oracle APEX 系列文章3：在阿里雲上打造屬於你本身的APEX完整開發環境 (安裝CentOS, Tomcat, Nginx)
• Oracle APEX 系列文章4：在阿里雲上打造屬於你本身的APEX完整開發環境 (安裝XE, ORDS, APEX)
• Oracle APEX 系列文章5：在阿里雲上打造屬於你本身的APEX完整開發環境 (進一步優化)
• Oracle APEX 系列文章6：Oracle APEX 到底適不適合企業環境？

鋼哥注：本文是一篇翻譯文章，原文做者： Joel R. Kallman（Oracle APEX 研發總監），原文請移步這裏：「 Is APEX Suitable for an Enterprise Setting?」。

不少人對 Oracle APEX 是否真的適合企業環境還心存顧慮，因此我以爲有必要作個解釋。就我我的的理解，IT 行業從有狗那年起就沒有銀彈。不論是從前的 SOA、企業服務總線，仍是如今的微服務架構、容器技術、無服務等。即便 BAT 這些一線互聯網大廠，公司內部也存在不少不一樣的應用框架和技術棧。別人家的架構永遠也只是別人家的，能借鑑的也就是個思路，而如今國內天天都在進行的各類「技術分享會」，也只能靠 「XX公司的技術架構演進之路」之類的話題來吸引人氣，由於沒有一個架構或技術適合全部的公司。架構或技術自己並無絕對的好壞之分，只有適不適合。（想爭論 PHP 是最好的編程語言的同窗請無視我，謝謝）

言歸正傳，下面是主要譯文。

Oracle APEX 18.1 最顯著的新特性就是有能力消費多種遠端數據源，從普通的 REST 數據源乃至基於 ORDS（Oracle REST Data Services）的遠程 SQL。直到 Oracle APEX 18.1 以前，數據庫鏈接（DB Link）還一直是訪問遠端 Oracle 數據庫的最廣泛方式。固然，這種數據庫鏈接在雲端環境是不存在的，而針對這方面的（功能）提高已然變成 Oracle APEX 18.1 的一個核心關注點。

一位具備多年經驗的 Oracle 顧問最近發表了一篇關於 Oracle APEX 的負面評論，他在博客中聲稱：

「在 Oracle 衆多的產品中，APEX 已然是（一種）過期的，單層的，與 Oracle Forms 相似古董（工具）。如今許多應用架構都基於 REST 服務了，而且其餘的 Oracle 工具，如： Oracle Jet, VBCS 和 ADF 長久以來就具有生成和（或）消費 REST 服務的能力。」

在我繼續（下面的話題）以前，我要糾正（他的）幾個觀點。首先，Oracle APEX 好久之前就已具有生產和消費 REST 以及 SOAP 服務的能力了。我（之因此）知道，是由於我早在2002年就受權了 APEX 針對 SOAP 服務的第一個支持。而且，您也不可能在 Oracle Jet 上生產 REST 服務，由於 Oracle Jet 是一個工具集，自己並不具有後端數據存儲（的功能），更沒有能力用來"支撐"一個 REST 服務。包括 Oracle 本身的 Oracle Jet 的產品經理們如今都在使用來自 Oracle APEX 上的 REST 服務來演示 Oracle Jet！最後，Oracle Jet 是2015年10月才發佈的，而 ABCS (如今叫「VBCS」) 也僅僅是2015年6月才發佈的初版。若是這就是這位顧問所謂的「長久以來就具有」的能力，那麼好吧。

回到（博主）提到的"過期的，單層的，不夠現代化"的問題。在迴應 Morten Braten (Oracle APEX 論壇社區的資深人士)的問詢時，該顧問聲稱「單層（應用）對於企業環境來講不多是好的選擇」，在迴應我關於什麼是"企業環境"的定義時，他僅僅援引了另外一篇講述「單層工具對企業是壞的」的網絡博文。

他質疑 Oracle APEX 架構的觀點之一是："數據在被其餘人看到以前必須先提交到數據庫"。我以爲這是個很奇怪的觀點。上一次我關注（這類問題）的時候，大部分的業務應用系統都是用來處理數據的。從如今（往前）倒推30年，咱們處理數據的界面和方法變動了十幾回了。然而，（企業應用系統）處理的仍然只是 - 數據。Billy Verreynne（一位資深 Oracle APEX 專家）曾在2005年評論道：「企業應用系統到底應該關注什麼？是數據！（數據）纔是最核心的，（數據）纔是驅動業務的關鍵。鐵打的數據，流水的應用。數據保存在哪裏？數據庫！數據庫纔是核心所在。數據庫自從上世紀80年代就出現了，而如今仍然在那裏。將關注點聚焦在數據上，爲了數據來設計，並有效利用好數據纔是企業應用設計的關鍵所在。」

我常常告訴人們，Oracle APEX 跟許多其餘技術的交叉點就是 Oracle 數據庫。Oracle APEX 是一個功能很是強大的應用開發環境，它同時也是一個帶有交互界面的設計開發引擎，跟這位顧問提到的許多企業應用框架是同樣的。併發性、事務完整性、持久性 - 這些問題 Oracle 數據庫早在許多年前就已經解決了。而且做爲獎勵，您同時還免費得到了零延遲的數據訪問能力。因此，「在任何人看到數據以前提交到數據庫」歷來不該該被認爲是缺陷，反而應該被考慮成是一個特性。

反觀「企業設置」這一術語，對於每一家企業而言，從簡單的應用到完整的關鍵業務應用，對應着不一樣的需求。若是把這些需求畫成一個圖，相似下面這種：

最底部表明最簡單的應用需求。這類應用應該是很是簡單就能夠實現的，複雜度很是低，基本一到兩我的就能夠開發完成，而且只有短暫的可預見的生命週期，這類應用每每都是 "機會主義" 類型的應用。

而圖的最上面則對應的是真正的企業關鍵應用需求。這類需求每每須要更大的團隊（一般10到20人，甚至更多的開發人員）、而且配備專職的項目經理，擁有專門的預算，系統複雜度和成本都很是高，開發的則是企業真正的關鍵核心應用系統。

那麼，Oracle APEX 可以解決的需求落在哪一個區間範圍內呢？我相信這也是我跟上面那位顧問最大的分歧所在。我相信 Oracle APEX 絕對能夠處理這裏面從下至上 90% 的需求。 雖然Oracle APEX 能夠被企業客戶用來開發大型 ERP、HR 和 CRM 系統，並支持數以千計的終端用戶的，但 Oracle APEX 真正的強項仍是在處理從下至上這 90% 的需求。

每家公司本身的應用系統（與真正的須要之間）都有差距。連做爲信息管理公司的 Oracle 公司 本身也會存在這種差距。沒有一個企業或應用系統能夠完美地解決全部的業務須要。問題是，咱們該如何來解決（這些問題）？仍是僅僅聽任自流，根本不去解決？企業架構師優先選擇的確定都是主流的、廣受支持的技術棧，但每每這些技術棧對大部分現有開發人員不是那麼容易可使用的，這也是爲何至今爲止 Excel 式的「系統」仍然在企業裏普遍使用的緣由。

上面那位顧問所信奉的企業架構都應該選擇最理想的技術來開發。但問題是，在上面的圖中，這類"理想"的技術對於開發數量衆多的簡單應用而言，在應用架構和相關技術棧層面，是否帶來了更多沒必要要的複雜度或成本開支呢？一家企業現存的應用系統中，能有多少能夠被稱爲真正的關鍵應用系統？10個？20個？30個？與之相對的倒是數以百計、千計乃至萬計的「非關鍵」應用系統。我很高興看到 Oracle APEX 能夠被用來快速解決掉這其中 90% 的需求，即便對於大型企業也依然如此。

在咱們 Oracle 內部，我天天也都能看到 Oracle APEX 正在解決這 90% 的需求，所覆蓋的範圍從跟蹤硬件資產分配 & 管理 到 旨在管理與區塊鏈案例相關的抵押品應用系統，再到能夠給財務部門提交薪資問題的應用系統 - 這類「90%」的需求的覆蓋面是很是廣的。問題是，被認爲是理想中的技術真正解決了這其中的多少需求？最終是用紙，仍是用一個電子表格來解決的？您是否更願意選擇一個基於 Oracle 數據庫的、久經考驗的、可擴展的低代碼開發框架，讓它來幫您完成 Web 應用開發中涉及到的全部方方面面，而您則能夠將注意力更專一於解決業務問題呢？是的，個人朋友，我說的這個框架就是 Oracle APEX！

---