摘要：很多人對(duì)是否真的適合企業(yè)環(huán)境還心存顧慮，所以我覺(jué)得有必要做個(gè)解釋。架構(gòu)或技術(shù)本身并沒(méi)有絕對(duì)的好壞之分，只有適不適合。沒(méi)有一個(gè)企業(yè)或應(yīng)用系統(tǒng)可以完美地解決所有的業(yè)務(wù)需要。

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

Oracle APEX 系列文章1：Oracle APEX, 讓你秒變?nèi)珬ｉ_(kāi)發(fā)的黑科技

Oracle APEX 系列文章2：在阿里云上打造屬于你自己的APEX完整開(kāi)發(fā)環(huán)境 (準(zhǔn)備工作)

Oracle APEX 系列文章3：在阿里云上打造屬于你自己的APEX完整開(kāi)發(fā)環(huán)境 (安裝CentOS, Tomcat, Nginx)

Oracle APEX 系列文章4：在阿里云上打造屬于你自己的APEX完整開(kāi)發(fā)環(huán)境 (安裝XE, ORDS, APEX)

Oracle APEX 系列文章5：在阿里云上打造屬于你自己的APEX完整開(kāi)發(fā)環(huán)境 (進(jìn)一步優(yōu)化)

Oracle APEX 系列文章6：Oracle APEX 到底適不適合企業(yè)環(huán)境？

鋼哥注：本文是一篇翻譯文章，原文作者：Joel R. Kallman（Oracle APEX 研發(fā)總監(jiān)），原文請(qǐng)移步這里：“Is APEX Suitable for an Enterprise Setting?”。
很多人對(duì) Oracle APEX 是否真的適合企業(yè)環(huán)境還心存顧慮，所以我覺(jué)得有必要做個(gè)解釋。就我個(gè)人的理解，IT 行業(yè)從有狗那年起就沒(méi)有銀彈。不管是從前的 SOA、企業(yè)服務(wù)總線，還是現(xiàn)在的微服務(wù)架構(gòu)、容器技術(shù)、無(wú)服務(wù)等。即使 BAT 這些一線互聯(lián)網(wǎng)大廠，公司內(nèi)部也存在很多不同的應(yīng)用框架和技術(shù)棧。別人家的架構(gòu)永遠(yuǎn)也只是別人家的，能借鑒的也就是個(gè)思路，而現(xiàn)在國(guó)內(nèi)每天都在進(jìn)行的各種“技術(shù)分享會(huì)”，也只能靠 “XX公司的技術(shù)架構(gòu)演進(jìn)之路”之類的話題來(lái)吸引人氣，因?yàn)闆](méi)有一個(gè)架構(gòu)或技術(shù)適合所有的公司。架構(gòu)或技術(shù)本身并沒(méi)有絕對(duì)的好壞之分，只有適不適合。（想爭(zhēng)論 PHP 是最好的編程語(yǔ)言的同學(xué)請(qǐng)無(wú)視我，謝謝）
言歸正傳，下面是主要譯文。

Oracle APEX 18.1 最顯著的新特性就是有能力消費(fèi)多種遠(yuǎn)端數(shù)據(jù)源，從普通的 REST 數(shù)據(jù)源乃至基于 ORDS（Oracle REST Data Services）的遠(yuǎn)程 SQL。直到 Oracle APEX 18.1 之前，數(shù)據(jù)庫(kù)連接（DB Link）還一直是訪問(wèn)遠(yuǎn)端 Oracle 數(shù)據(jù)庫(kù)的最普遍方式。當(dāng)然，這種數(shù)據(jù)庫(kù)連接在云端環(huán)境是不存在的，而針對(duì)這方面的（功能）提升已然變成 Oracle APEX 18.1 的一個(gè)核心關(guān)注點(diǎn)。

一位具有多年經(jīng)驗(yàn)的 Oracle 顧問(wèn)最近發(fā)表了一篇關(guān)于 Oracle APEX 的負(fù)面評(píng)論，他在博客中聲稱：

“在 Oracle 眾多的產(chǎn)品中，APEX 已然是（一種）過(guò)時(shí)的，單層的，與 Oracle Forms 類似古董（工具）?，F(xiàn)在許多應(yīng)用架構(gòu)都基于 REST 服務(wù)了，并且其他的 Oracle 工具，如：Oracle Jet, VBCS 和 ADF 長(zhǎng)久以來(lái)就具備生成和（或）消費(fèi) REST 服務(wù)的能力?！?/pre>
在我繼續(xù)（下面的話題）之前，我要糾正（他的）幾個(gè)觀點(diǎn)。首先，Oracle APEX 很久以前就已具備生產(chǎn)和消費(fèi) REST 以及 SOAP 服務(wù)的能力了。我（之所以）知道，是因?yàn)槲以缭?002年就授權(quán)了 APEX 針對(duì) SOAP 服務(wù)的第一個(gè)支持。并且，您也不可能在 Oracle Jet 上生產(chǎn) REST 服務(wù)，因?yàn)?Oracle Jet 是一個(gè)工具集，本身并不具備后端數(shù)據(jù)存儲(chǔ)（的功能），更沒(méi)有能力用來(lái)"支撐"一個(gè) REST 服務(wù)。包括 Oracle 自己的 Oracle Jet 的產(chǎn)品經(jīng)理們現(xiàn)在都在使用來(lái)自 Oracle APEX 上的 REST 服務(wù)來(lái)演示 Oracle Jet！最后，Oracle Jet 是2015年10月才發(fā)布的，而 ABCS (現(xiàn)在叫“VBCS”) 也僅僅是2015年6月才發(fā)布的第一版。如果這就是這位顧問(wèn)所謂的“長(zhǎng)久以來(lái)就具備”的能力，那么好吧。
回到（博主）提到的"過(guò)時(shí)的，單層的，不夠現(xiàn)代化"的問(wèn)題。在回應(yīng) Morten Braten (Oracle APEX 論壇社區(qū)的資深人士)的問(wèn)詢時(shí)，該顧問(wèn)聲稱“單層（應(yīng)用）對(duì)于企業(yè)環(huán)境來(lái)說(shuō)很少是好的選擇”，在回應(yīng)我關(guān)于什么是"企業(yè)環(huán)境"的定義時(shí)，他僅僅援引了另一篇講述“單層工具對(duì)企業(yè)是壞的”的網(wǎng)絡(luò)博文。
他質(zhì)疑 Oracle APEX 架構(gòu)的觀點(diǎn)之一是："數(shù)據(jù)在被其他人看到之前必須先提交到數(shù)據(jù)庫(kù)"。我覺(jué)得這是個(gè)很奇怪的觀點(diǎn)。上一次我關(guān)注（這類問(wèn)題）的時(shí)候，大部分的業(yè)務(wù)應(yīng)用系統(tǒng)都是用來(lái)處理數(shù)據(jù)的。從現(xiàn)在（往前）倒推30年，我們處理數(shù)據(jù)的界面和方法變更了十幾次了。然而，（企業(yè)應(yīng)用系統(tǒng)）處理的仍然只是 - 數(shù)據(jù)。Billy Verreynne（一位資深 Oracle APEX 專家）曾在2005年評(píng)論道：“企業(yè)應(yīng)用系統(tǒng)到底應(yīng)該關(guān)注什么？是數(shù)據(jù)?。〝?shù)據(jù)）才是最核心的，（數(shù)據(jù)）才是驅(qū)動(dòng)業(yè)務(wù)的關(guān)鍵。鐵打的數(shù)據(jù)，流水的應(yīng)用。數(shù)據(jù)保存在哪里？數(shù)據(jù)庫(kù)！數(shù)據(jù)庫(kù)才是核心所在。數(shù)據(jù)庫(kù)自從上世紀(jì)80年代就出現(xiàn)了，而現(xiàn)在仍然在那里。將關(guān)注點(diǎn)聚焦在數(shù)據(jù)上，為了數(shù)據(jù)來(lái)設(shè)計(jì)，并有效利用好數(shù)據(jù)才是企業(yè)應(yīng)用設(shè)計(jì)的關(guān)鍵所在?！?/b>

我經(jīng)常告訴人們，Oracle APEX 跟許多其他技術(shù)的交叉點(diǎn)就是 Oracle 數(shù)據(jù)庫(kù)。Oracle APEX 是一個(gè)功能非常強(qiáng)大的應(yīng)用開(kāi)發(fā)環(huán)境，它同時(shí)也是一個(gè)帶有交互界面的設(shè)計(jì)開(kāi)發(fā)引擎，跟這位顧問(wèn)提到的許多企業(yè)應(yīng)用框架是一樣的。并發(fā)性、事務(wù)完整性、持久性 - 這些問(wèn)題 Oracle 數(shù)據(jù)庫(kù)早在許多年前就已經(jīng)解決了。并且作為獎(jiǎng)勵(lì)，您同時(shí)還免費(fèi)獲得了零延遲的數(shù)據(jù)訪問(wèn)能力。所以，“在任何人看到數(shù)據(jù)之前提交到數(shù)據(jù)庫(kù)”從來(lái)不應(yīng)該被認(rèn)為是缺陷，反而應(yīng)該被考慮成是一個(gè)特性。
反觀“企業(yè)設(shè)置”這一術(shù)語(yǔ)，對(duì)于每一家企業(yè)而言，從簡(jiǎn)單的應(yīng)用到完整的關(guān)鍵業(yè)務(wù)應(yīng)用，對(duì)應(yīng)著不同的需求。如果把這些需求畫成一個(gè)圖，類似下面這種：

最底部代表最簡(jiǎn)單的應(yīng)用需求。這類應(yīng)用應(yīng)該是非常簡(jiǎn)單就可以實(shí)現(xiàn)的，復(fù)雜度非常低，基本一到兩個(gè)人就可以開(kāi)發(fā)完成，并且只有短暫的可預(yù)見(jiàn)的生命周期，這類應(yīng)用往往都是 "機(jī)會(huì)主義" 類型的應(yīng)用。
而圖的最上面則對(duì)應(yīng)的是真正的企業(yè)關(guān)鍵應(yīng)用需求。這類需求往往需要更大的團(tuán)隊(duì)（通常10到20人，甚至更多的開(kāi)發(fā)人員）、并且配備專職的項(xiàng)目經(jīng)理，擁有專門的預(yù)算，系統(tǒng)復(fù)雜度和成本都非常高，開(kāi)發(fā)的則是企業(yè)真正的關(guān)鍵核心應(yīng)用系統(tǒng)。
那么，Oracle APEX 能夠解決的需求落在哪個(gè)區(qū)間范圍內(nèi)呢？我相信這也是我跟上面那位顧問(wèn)最大的分歧所在。我相信 Oracle APEX 絕對(duì)可以處理這里面從下至上 90% 的需求。 雖然Oracle APEX 可以被企業(yè)客戶用來(lái)開(kāi)發(fā)大型 ERP、HR 和 CRM 系統(tǒng)，并支持?jǐn)?shù)以千計(jì)的終端用戶的，但 Oracle APEX 真正的強(qiáng)項(xiàng)還是在處理從下至上這 90% 的需求。

每家公司自己的應(yīng)用系統(tǒng)（與真正的需要之間）都有差距。連作為信息管理公司的 Oracle 公司 自己也會(huì)存在這種差距。沒(méi)有一個(gè)企業(yè)或應(yīng)用系統(tǒng)可以完美地解決所有的業(yè)務(wù)需要。問(wèn)題是，我們?cè)撊绾蝸?lái)解決（這些問(wèn)題）？還是僅僅放任自流，根本不去解決？企業(yè)架構(gòu)師優(yōu)先選擇的肯定都是主流的、廣受支持的技術(shù)棧，但往往這些技術(shù)棧對(duì)大部分現(xiàn)有開(kāi)發(fā)人員不是那么容易可以使用的，這也是為什么至今為止 Excel 式的“系統(tǒng)”仍然在企業(yè)里廣泛使用的原因。
上面那位顧問(wèn)所信奉的企業(yè)架構(gòu)都應(yīng)該選擇最理想的技術(shù)來(lái)開(kāi)發(fā)。但問(wèn)題是，在上面的圖中，這類"理想"的技術(shù)對(duì)于開(kāi)發(fā)數(shù)量眾多的簡(jiǎn)單應(yīng)用而言，在應(yīng)用架構(gòu)和相關(guān)技術(shù)棧層面，是否帶來(lái)了更多不必要的復(fù)雜度或成本開(kāi)支呢？一家企業(yè)現(xiàn)存的應(yīng)用系統(tǒng)中，能有多少可以被稱為真正的關(guān)鍵應(yīng)用系統(tǒng)？10個(gè)？20個(gè)？30個(gè)？與之相對(duì)的卻是數(shù)以百計(jì)、千計(jì)乃至萬(wàn)計(jì)的“非關(guān)鍵”應(yīng)用系統(tǒng)。我很高興看到 Oracle APEX 可以被用來(lái)快速解決掉這其中 90% 的需求，即使對(duì)于大型企業(yè)也依然如此。
在我們 Oracle 內(nèi)部，我每天也都能看到 Oracle APEX 正在解決這 90% 的需求，所覆蓋的范圍從跟蹤硬件資產(chǎn)分配 & 管理 到 旨在管理與區(qū)塊鏈案例相關(guān)的抵押品應(yīng)用系統(tǒng)，再到可以給財(cái)務(wù)部門提交薪資問(wèn)題的應(yīng)用系統(tǒng) - 這類“90%”的需求的覆蓋面是非常廣的。問(wèn)題是，被認(rèn)為是理想中的技術(shù)真正解決了這其中的多少需求？最終是用紙，還是用一個(gè)電子表格來(lái)解決的？您是否更愿意選擇一個(gè)基于 Oracle 數(shù)據(jù)庫(kù)的、久經(jīng)考驗(yàn)的、可擴(kuò)展的低代碼開(kāi)發(fā)框架，讓它來(lái)幫您完成 Web 應(yīng)用開(kāi)發(fā)中涉及到的所有方方面面，而您則可以將注意力更專注于解決業(yè)務(wù)問(wèn)題呢？是的，我的朋友，我說(shuō)的這個(gè)框架就是 Oracle APEX！