摘要：實際上，多年前，關系數據庫的相關論文，就已經論證了基于關系運算理論來表達客觀世界的完備性，所以上面的理想情況才變得那么合情合理。

一看這標題，你肯定會認為基本不可能，或者認為，不寫代碼最多只能做一些簡單業務場景實現。

為了達成我們的目標，先來看看常規企業級應用開發的基本過程：

第一步，數據庫建表建字段。

第二步，在應用代碼里創建跟表對應的業務對象，并實現及涉及到對象之間關系的操作方法。

第三步，UI 層調用業務對象獲取數據做渲染，或者通過業務對象做持久化操作。

受常規開發思維慣性，我們會理所當然地認為，要完成第二步、第三步，不寫業務代碼，而只寫 SQL，做配置，就完成各種五花八門的業務邏輯，幾乎是不可能。

讓我們需要回歸一個業務系統的本質，來看看第二步和第三步到底做了什么。我們想象這樣一種理想情況：如果終端用戶自己就是 SQL 高手，那么他應該是完全有可能僅僅通過一個 SQL 客戶端完成所有業務邏輯的。實際上，40 多年前，關系數據庫的相關論文，就已經論證了基于關系運算理論來表達客觀世界的完備性，所以上面的理想情況才變得那么合情合理。
那么我們不禁要問，在數據庫上層開發出來的業務系統，究竟是要解決什么核心問題？

前面已陳述，關系運算理論及 SQL(已經非常接近自然語言) 以其本身的完備性，已經可以處理各種復雜的業務邏輯。那么顯然，我們在上層創建的應用，顯然不是為了解決數據庫自身實現不了的業務邏輯，而額外做的代碼工作，而是為了給不懂 SQL 的人提供的一個外殼，讓他們基于這個相對固定交互的 UI 外殼，通過一些簡單的操作比如點擊鼠標，就能方便而并正確地完成一些背后的 SQL 操作。

【圖一 單系統數據流】

為了實現上述固定交互的 UI 外殼，我們不得不在應用層，采用面向對象的方法去串接邏輯，此時又不得不做一些對象和實體關系映射(ORM)的工作。這也是關系建模體系和面向對象思維天生的沖突所在：前者是經過嚴格的數學和形式化推導論證過的完備建模體系，后者是編程開發模式上的一種最佳實踐。雖然有一些優秀的 ORM 框架如 hibernate 和 mybatis 來解決這類問題，但不要忘記，我們完成業務邏輯的核心就在于 SQL 的執行。而為了達成這一目標，ORM 的做法似乎有些舍近求遠。那么，能不能去掉第二步和第三步，只寫 SQL 做配置就能完成系統開發呢？

考察常規開發的第三步工作，會發現最終產出物實際上就是讓用戶在 UI 上操作完成背后對應的數據庫的 IO 操作，所以我們可以從輸入輸出這兩方面發掘本質需求：

一方面（OUTPUT），由于關系數據庫基于表、字段的結構化表示，一條 SELECT 語句執行的結果是可以在沒有中間代碼加工的情況下直接在頁面上呈現的。只要 UI 層的各個組件比如列表、表格、卡片支持對相關數據的渲染呈現即可。

另一方面（INPUT），用戶做的相關持久化操作，此過程比較程式化，即從頁面上取得各種各樣的數據，匯總到后臺執行 UPDATE、INSERT、DELETE 等一條或者多條 SQL(含事務) 操作，當然中間可能有一些 IF ELSE 的處理細節。

于是，為了達成本文的開題目標，我們做了Enhancer 云開發工作臺，它是一個專門用于企業級信息系統開發的一站式工作臺，用戶可以基于此工作臺，基本只需要寫 SQL 做配置，就能快速完成全部開發工作，并且獲得可以私有部署的系統。這個工作臺，作為具備完整開發功能的云 IDE，還主要做了以下兩方面的工作來達成只寫 SQL 做配置就能完成開發的目標：

一方面，它構建了一個標準化 UI 組件庫（支持三方擴展），讓組件的使用過程以配置化的形式呈現給開發者，直接對接 SQL 做數據組織或呈現。

另一方面，提供一套完備的變量數據體系和程式化的事件動作響應機制，讓開發者根據這種程式化的模式，快速地完成各種復雜的業務數據持久化操作。

【圖二 Enhancer 所見即所得開發示意】

經過實戰檢驗，這種開發模式，比常規開發模式快至少 10 倍，并且迭代及維護成本都大大降低。目前已有上萬名開發者使用該平臺，完成了涵蓋各個行業各種復雜信息管理應用場景的系統，見案例。與其他低代碼(low-code)開發工具只能開發簡單的業務系統不同，Enhancer 基于Z-Model 理論在開發模型上的完備性，支持全業務場景開發，沒有任何技術限制，歡迎嘗試并指教。