Oracle APEX 系列文章6：Oracle APEX 到底适不适合企业环境？

时间 2019-11-16

标签 oracle apex 系列文章到底不适合企业环境栏目 Oracle 繁體版

原文原文链接

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

钢哥注：本文是一篇翻译文章，原文做者： 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

我常常告诉人们，Oracle APEX 跟许多其余技术的交叉点就是 Oracle 数据库。Oracle APEX 是一个功能很是强大的应用开发环境，它同时也是一个带有交互界面的设计开发引擎，跟这位顾问提到的许多企业应用框架是同样的。并发性、事务完整性、持久性 - 这些问题 Oracle 数据库早在许多年前就已经解决了。而且做为奖励，您同时还免费得到了零延迟的数据访问能力。因此，“在任何人看到数据以前提交到数据库”历来不该该被认为是缺陷，反而应该被考虑成是一个特性。app

反观“企业设置”这一术语，对于每一家企业而言，从简单的应用到完整的关键业务应用，对应着不一样的需求。若是把这些需求画成一个图，相似下面这种：框架

最底部表明最简单的应用需求。这类应用应该是很是简单就能够实现的，复杂度很是低，基本一到两我的就能够开发完成，而且只有短暂的可预见的生命周期，这类应用每每都是 "机会主义" 类型的应用。

而图的最上面则对应的是真正的企业关键应用需求。这类需求每每须要更大的团队（一般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！