為什麼我不再使用MVC框架？

Jean-Jacques Dubray 是一名資深工程師，他最近引入了一個新的模式：狀態-行為-模型（State-Action-Model，SAM）。SAM 是一個函式式反應型的程式設計模式，它致力於簡化資料 Model 和 View 之間的互動。它究竟有何優點值得作者棄用 MVC 呢？

話題起因

在我最近的工作中，最讓人抓狂的就是為前端開發人員設計 API。我們之間的對話大致就是這樣的：

開發人員：這個頁面上有資料元素x，y，z…，你能不能為我建立一個 API，響應格式為{x: ， y:, z: }

我：好吧

我甚至沒有進行進一步的爭論。專案結束時會積累大量的 API，這些 API 與經常發生變化的頁面是關聯在一起的，按照“設計”，只要頁面改變，相應的 API 也要隨之變化，而在此之前，我們甚至對此毫不知情，最終，由於形成因素眾多且各平臺之間存在些許差異，必須建立非常多的 API 來滿足這些需求。

Sam Newman 甚至將這種制度化的過程稱之為BFF 模式，這種模式建議為每種裝置、平臺當然還包含 APP 版本開發特定的 API。 Daniel Jacobson 在接受 InfoQ 的採訪時曾指出，Netflix 頗為勉強地將“體驗式 API”與“臨時 API（Ephemeral API）”劃上了等號。 唉……

幾個月前，我開始思考是什麼造成了如今的這種現象，該做些什麼來應對它，這個過程使我開始質疑應用架構中最強大的理念，也就是 MVC，我感受到了函式式反應型程式設計（reactive）的強大威力，這個過程致力於流程的簡化，並試圖消除我們這個行業在生產率方面的膨脹情緒。我相信你會對我的發現感興趣的。

MVC 的輝煌過去與現存問題

在每個使用者介面背後，我們都在使用 MVC 模式，也就是模型-檢視-控制器（Model-View-Controller）。MVC 發明的時候，Web 尚不存在，當時的軟體架構充其量是胖客戶端在原始網路中直接與單一資料庫會話。但是，幾十年之後，MVC 依然在使用，持續地用於 OmniChannel 應用的構建。

Angular 2 正式版即將釋出，在這個時間節點重估 MVC 模式及各種 MVC 框架為應用架構帶來的貢獻意義重大。

我第一次接觸到 MVC 是在 1990 年，當時 NeXT 剛剛釋出 Interface Builder（讓人驚訝的是，如今這款軟體依然發揮著重大的作用）。當時，我們感覺 Interface Builder 和 MVC 是一個很大的進步。在 90 年代末期，MVC 模式用到了 HTTP 上的任務中（還記得 Struts 嗎？），如今，就各個方面來講，MVC 是所有應用架構的基本原則。

MVC 的影響十分深遠，以致於 React.js 在介紹他們的框架時都委婉地與其劃清界限：“React 實現的只是 MVC 中檢視（View）的部分”。

當我去年開始使用 React 的時候，我感覺它在某些地方有著明顯的不同：你在某個地方修改一部分資料，不需要顯式地與 View 和 Model 進行互動，整個 UI 就能瞬間發生變化（不僅僅是域和表格中的值）。這也就是說，我很快就對 React 的程式設計模型感到了失望，在這方面，我顯然並不孤獨。我分享一下 Andre Medeiros 的觀點：

React 在很多方面都讓我感到失望，它主要是通過設計不佳的 API 來引導程式設計師[…]將多項關注點混合到一個元件之中。

作為服務端的 API 設計者，我的結論是沒有特別好的方式將 API 呼叫組織到 React 前端中，這恰恰是因為 React 只關注 View，在它的程式設計模型中根本不存在控制器。

到目前為止，Facebook 一直致力於在框架層面彌合這一空白。React 團隊起初引入了 Flux 模式，不過它依然令人失望，最近 Dan Abramov 又提倡另外一種模式，名為 Redux，在一定程度上來講，它的方向是正確的，但是在將 API 關聯到前端方面，依然比不上我下面所介紹的方案。

Google 釋出過 GWT、Android SDK 還有 Angular，你可能認為他們的工程師熟知何為最好的前端架構，但是當你閱讀 Angular 2 設計考量的文章時，便會不以為然，即便在 Google 大家也達成這樣的共識，他們是這樣評價之前的工作成果的：

Angular 1 並不是基於元件的理念構建的。相反，我們需要將控制器與頁面上各種[元素]進行關聯（attach），其中包含了我們的自定義邏輯。根據我們自定義的指令如何對其進行封裝（是否包含 isolate scope？），scope 會進行關聯或繼續往下傳遞。

基於元件的 Angular 2 看起來能簡單一點嗎？其實並沒有好多少。Angular 2 的核心包本身就包含了 180 個語義（Semantics），整個框架的語義已經接近 500 個，這是基於 HTML5 和 CSS3 的。誰有那麼多時間學習和掌握這樣的框架來構建 Web 應用呢？當 Angular 3 出現的時候，情況又該是什麼樣子呢？

在使用過 React 並瞭解了 Angular 2 將會是什麼樣子之後，我感到有些沮喪：這些框架都系統性地強制我使用 BFF“頁面可替換模式（Screen Scraping）”模式，按照這種模式，每個服務端的 API 要匹配頁面上的資料集，不管是輸入的還是輸出的。

棄用 MVC 之後怎麼走？

此時，我決定“讓這一切見鬼去吧”。我構建了一個 Web 應用，沒有使用 React、沒有使用 Angular 也沒有使用任何其他的 MVC 框架，通過這種方式，我看一下是否能夠找到一種在 View 和底層 API 之間進行更好協作的方式。

就 React 來講，我最喜歡的一點在於 Model 和 View 之間的關聯關係。React 不是基於模板的，View 本身沒有辦法請求資料（我們只能將資料傳遞給 View），看起來，針對這一點進行探索是一個很好的方向。

如果看得足夠長遠的話，你會發現 React 唯一的目的就是將 View 分解為一系列（純粹的）函式和 JSX 語法：

 <V params={M}/>

它實際上與下面的格式並沒有什麼差別：

 V = f ( M )

例如，我當前正在從事專案的 Web 站點， Gliiph，就是使用這種函式構建的：

圖1：用於生成站點 Slider 元件 HTML 的函式

這個函式需要使用 Model 來填充資料：

圖2：支撐 slider 的 Model

如果用簡單的 JavaScript 函式就能完成任務，我們為什麼還要用 React 呢？

虛擬 DOM（virtual-dom）？如果你覺得需要這樣一種方案的話（我並不確定有很多的人需要這樣），其實有這樣的可選方案，我也期望開發出更多的方案。

GraphQL？並不完全如此。不要因為 Facebook 大量使用它就對其產生誤解，認為它一定是對你有好處的。GraphQL 僅僅是以宣告的方式來建立檢視模型。強制要求 Model 匹配 View 會給你帶來麻煩，而不是解決方案。React 團隊可能會覺得使用“客戶端指定查詢（Client-specified queries）”是沒有問題的（就像反應型團隊中那樣）：

GraphQL 完全是由 View 以及編寫它們的前端工程師的需求所驅動的。[…]另一方面，GraphQL 查詢會精確返回客戶端請求的內容，除此之外，也就沒什麼了。

GraphQL 團隊沒有關注到 JSX 語法背後的核心思想：用函式將 Model 與 View 分離。與模板和“前端工程師所編寫的查詢”不同，函式不需要 Model 來適配 View。

當 View 是由函式建立的時候（而不是由模板或查詢所建立），我們就可以按需轉換 Model，使其按照最合適的形式來展現 View，不必在 Model 的形式上新增人為的限制。

例如，如果 View 要展現一個值v，有一個圖形化的指示器會標明這個值是優秀、良好還是很差，我們沒有理由將指示器的值放到 Model 中：函式應該根據 Model 所提供的v值，來進行簡單的計算，從而確定指示器的值。

現在，把這些計算直接嵌入到 View 中並不是什麼好主意，使 View-Model 成為一個純函式也並非難事，因此當我們需要明確的 View-Model 時，就沒有特殊的理由再使用 GraphQL 了：

V = f ( vm (M) )

作為深諳 MDE 之道的人，我相信你更善於編寫程式碼，而不是後設資料，不管它是模板還是像 GraphQL 這樣的複雜查詢語言。

這個函式式的方式能夠帶來多項好處。首先，與 React 類似，它允許我們將 View 分解為元件。它們建立的較為自然的介面允許我們為 Web 應用或 Web 站點設定“主題”，或者使用不同的技術來渲染 View（如原生的方式）。函式實現還有可能增強我們實現反應型設計的方式。

在接下來的幾個月中，可能會出現開發者交付用 JavaScript 函式包裝的基於元件的 HTML5 主題的情況。這也是最近這段時間，在我的 Web 站點專案中，我所採用的方式，我會得到一個模板，然後迅速地將其封裝為 JavaScript 函式。我不再使用 WordPress。基本上花同等的工夫（甚至更少），我就能實現 HTML5 和 CSS 的最佳效果。

這種方式也需要在設計師和開發人員之間建立一種新型的關係。任何人都可以編寫這些 JavaScript 函式，尤其是模板的設計人員。人們不需要學習繫結方法、JSX 和 Angular 模板的語法，只掌握簡單的 JavaScript 核心函式就足以讓這一切運轉起來。

有意思的是，從反應型流程的角度來說，這些函式可以部署在最合適的地方：在服務端或在客戶端均可。

但最為重要的是，這種方式允許在 View 與 Model 之間建立最小的契約關係，讓 Model 來決定如何以最好的方式將其資料傳遞給 View。讓 Model 去處理諸如快取、懶載入、編配以及一致性的問題。與模板和 GraphQL 不同，這種方式不需要從 View 的角度來直接傳送請求。

既然我們有了一種方式將 Model 與 View 進行解耦，那麼下一個問題就是：在這裡該如何建立完整的應用模型呢？“控制器”該是什麼樣子的？為了回答這個問題，讓我們重新回到 MVC 上來。

蘋果公司瞭解 MVC 的基本情況，因為他們在上世紀 80 年代初，從 Xerox PARC“偷來了”這一模式，從那時起，他們就堅定地實現這一模式：

圖3：MVC 模式

Andre Medeiros 曾經清晰地指出，這裡核心的缺點在於， MVC 模式是“互動式的（interactive）”（這與反應型截然不同）。在傳統的 MVC 之中，Action（Controller）將會呼叫 Model 上的更新方法，在成功（或出錯）之時會確定如何更新 View。他指出，其實並非必須如此，這裡還有另外一種有效的、反應型的處理方式，我們只需這樣考慮，Action 只應該將值傳遞給 Model，不管輸出是什麼，也不必確定 Model 該如何進行更新。

那核心問題就變成了：該如何將 Action 整合到反應型流程中呢？如果你想理解 Action 的基礎知識的話，那麼你應該看一下 TLA+。TLA 代表的是“Action 中的邏輯時序（Temporal Logic of Actions）”，這是由 Dr. Lamport 所提出的學說，他也因此獲得了圖靈獎。在 TLA+ 中，Action 是純函式：

data’ = A (data)

我真的非常喜歡 TLA+ 這個很棒的理念，因為它強制函式只轉換給定的資料集。

按照這種形式，反應型 MVC 看起來可能就會如下所示：

V = f ( M.present ( A (data) ) )

這個表示式規定當 Action 觸發的時候，它會根據一組輸入（例如使用者輸入）計算一個資料集，這個資料是提交到 Model 中的，然後會確定是否需要以及如何對其自身進行更新。當更新完成後，View 會根據新的 Model 狀態進行更新。反應型的環就閉合了。Model 持久化和獲取其資料的方式是與反應型流程無關的，所以，它理所應當地“不應該由前端工程師來編寫”。不必因此而感到歉意。

再次強調，Action 是純函式，沒有狀態和其他的副作用（例如，對於 Model，不會包含計數的日誌）。

反應型 MVC 模式很有意思，因為除了 Model 以外，所有的事情都是純函式。公平來講，Redux 實現了這種特殊的模式，但是帶有 React 不必要的形式，並且在 reducer 中，Model 和 Action 之間存在一點不必要的耦合。Action 和介面之間是純粹的訊息傳遞。

這也就是說，反應型 MVC 並不完整，按照 Dan 喜歡的說法，它並沒有擴充套件到現實的應用之中。讓我們通過一個簡單的樣例來闡述這是為什麼。

假設我們需要實現一個應用來控制火箭的發射：一旦我們開始倒數計時，系統將會遞減計數器（counter），當它到達零的時候，會將 Model 中所有未定的狀態設定為規定值，火箭的發射將會進行初始化。

這個應用有一個簡單的狀態機：

圖4：火箭發射的狀態機

其中 decrement 和 launch 都是“自動”的 Action，這意味著我們每次進入（或重新進入）counting 狀態時，將會保證進行轉換的評估，如果計數器的值大於零的話，decrement Action 將會繼續呼叫，如果值為零的話，將會呼叫 launchAction。在任何的時間點都可以觸發 abort Action，這樣的話，控制系統將會轉換到 aborted 狀態。

在 MVC 中，這種型別的邏輯將會在控制器中實現，並且可能會由 View 中的一個計時器來觸發。

這一段至關重要，所以請仔細閱讀。我們已經看到，在 TLA+ 中，Action 沒有副作用，只是計算結果的狀態，Model 處理 Action 的輸出並對其自身進行更新。這是與傳統狀態機語義的基本區別，在傳統的狀態機中，Action 會指定結果狀態，也就是說，結果狀態是獨立於 Model 的。

在 TLA+ 中，所啟用的 Action 能夠在狀態表述（也就是 View）中進行觸發，這些 Action 不會直接與觸發狀態轉換的行為進行關聯。換句話說，狀態機不應該由連線兩個狀態的元組（S1, A, S2）來進行指定，傳統的狀態機是這樣做的，它們元組的形式應該是（Sk, Ak1, Ak2,…），這指定了所有啟用的 Action，並給定了一個狀態 Sk，Action 應用於系統之後，將會計算出結果狀態，Model 將會處理更新。

當我們引入“state”物件時，TLA+ 提供了一種更優秀的方式來對系統進行概念化，它將 Action 和 view（僅僅是一種狀態的表述）進行了分離。

我們樣例中的 Model 如下所示：

model = {
       counter:  ,
       started:  ,
       aborted:  ,
       launched:   
}

系統中四個（控制）狀態分別對應於 Model 中如下的值：

ready = {counter: 10, started: false, aborted: false, launched: false }
counting = {counter: [0..10], started: true, aborted: false, launched: false }
launched = {counter: 0, started: true, aborted: false, launched: true}
aborted = {counter: [0..10], started: true, aborted: true, launched: false}

這個 Model 是由系統的所有屬性及其可能的值所指定的，狀態則指定了所啟用的 Action，它會給定一組值。這種型別的業務邏輯必須要在某個地方進行實現。我們不能指望使用者能夠知道哪個 Action 是否可行。在這方面，沒有其他的方式。不過，這種型別的業務邏輯很難編寫、除錯和維護，在沒有語義對其進行描述時，更是如此，比如在 MVC 中就是這樣。

讓我們為火箭發射的樣例編寫一些程式碼。從 TLA+ 角度來講，next-action 斷言在邏輯上會跟在狀態渲染之後。當前狀態呈現之後，下一步就是執行 next-action 斷言，如果存在的話，將會計算並執行下一個 Action，這個 Action 會將其資料交給 Model，Model 將會初始化新狀態的表述，以此類推。

圖5：火箭發射器的實現

需要注意的是，在客戶端/伺服器架構下，當自動 Action 觸發之後，我們可能需要使用像 WebSocket 這樣的協議（或者在 WebSocket 不可用的時候，使用輪詢機制）來正確地渲染狀態表述。

我曾經使用 Java 和 JavaScript 編寫過一個很輕量級的開源庫，它使用 TLA+ 特有的語義來構造狀態物件，並提供了樣例，這些樣例使用 WebSocket、輪詢和佇列實現瀏覽器/伺服器互動。在火箭發射器的樣例中可以看到，我們並非必須要使用那個庫。一旦理解了如何編寫，狀態實現的編碼相對來講是很容易的。

新模式——SAM 模式

對於要引入的新模式來說，我相信我們已經具備了所有的元素，這個新模式作為 MVC 的替代者，名為 SAM 模式（狀態-行為-模型，State-Action-Model），它具有反應型和函式式的特性，靈感來源於 React.js 和 TLA+。

SAM 模式可以通過如下的表示式來進行描述：

V = S ( vm ( M.present ( A (data) ) )， nap (M))

它表明在應用一個 Action A 之後，View V 可以計算得出，Action 會作為 Model 的純函式。

在 SAM 中，A（Action）、vm（檢視-模型，view-model）、nap（next-action 斷言）以及S（狀態表述）必須都是純函式。在 SAM 中，我們通常所說的“狀態”（系統中屬性的值）要完全侷限於 Model 之中，改變這些值的邏輯在 Model 本身之外是不可見的。

隨便提一下，next-action 斷言，即 nap ()是一個回撥，它會在狀態表述建立完成，並渲染給使用者時呼叫。

圖7：“修改地址”的實現

模式中的元素，包括 Action 和 Model，可以進行自由地組合：

函式組合

data’ = A (B(data))

端組合（Peer）（相同的資料集可以提交給兩個 Model）

M1.present (data’)

M2.present (data’)

父子組合（父 Model 控制的資料集提交給子 Model）

M1.present (data’,M2)
function present (data, child) {
            // 執行更新
            …
            // 同步 Model
            child.present (c(data))
}

釋出/訂閱組合

M1.on (“topic”， present )

M2.on (“topic”， present )

或

M1.on (“data”， present )

M2.on (“data”， present )

有些架構師可能會考慮到 System of Record 和 Systems of Engagement，這種模式有助於明確這兩層的介面（圖8），Model 會負責與 systems of record 的互動。

圖8：SAM 組合模型

整個模式本身也是可以進行組合的，我們可以實現執行在瀏覽器中的 SAM 例項，使其支援類似於嚮導（wizard）的行為（如 ToDo 應用），它會與伺服器端的 SAM 進行互動：

圖9：SAM 例項組合

請注意，裡層的 SAM 例項是作為狀態表述的一部分進行傳送的，這個狀態表述是由外層的例項所生成的。

會話檢查應該在 Action 觸發之前進行（圖 10）。SAM 能夠啟用一項很有意思的組合，在將資料提交給 Model 之前，View 可以呼叫一個第三方的 Action，並且要為其提供一個 token 和指向系統 Action 的回撥，這個第三方 Action 會進行授權並校驗該呼叫的合法性。

圖 10：藉助 SAM 實現會話管理

從 CQRS 的角度來講，這個模式沒有對查詢（Query）和命令（Command）做特殊的區分，但是底層的實現需要進行這種區分。搜尋或查詢“Action”只是簡單地傳遞一組引數到 Model 中。我們可以採用某種約定（如下劃線字首）來區分查詢和命令，或者我們可以在 Model 上使用兩個不同的 present 方法：

{ _name : ‘/^[a]$/i’ } // 名字以A或a開頭

{ _customerId: ‘123’ } // id=123 的 customer

Model 將會執行必要的操作以匹配查詢，更新其內容並觸發 View 的渲染。類似的約定可以用於建立、更新或刪除 Model 中的元素。在將 Action 的輸出傳遞給 Model 方面，我們可以實現多種方式（資料集、事件、Action……）。每種方式都會有其優勢和不足，最終這取決於個人偏好。我更喜歡資料集的方式。

在異常方面，與 React 類似，我們預期 Model 會以屬性值的形式儲存異常資訊（這些屬性值可能是由 Action 提交的，也可能是 CRUD 操作返回的）。在渲染狀態表述的時候，會用到屬性值，以展現異常資訊。

在快取方面，SAM 在狀態表述層提供了快取的選項。直觀上來看，快取這些狀態表述函式的結果能夠實現更高的命中率，因為我們現在是在元件/狀態層觸發快取，而不是在 Action/響應層。

該模式的反應型和函式式結構使得功能重放（replay）和單元測試變得非常容易。

SAM 模式完全改變了前端架構的正規化，因為根據 TLA+ 的基礎理念，業務邏輯可以清晰地描述為：

• Action 是純函式
• CRUD 操作放在 Model 中
• 狀態控制自動化的 Action

作為 API 的設計者，從我的角度來講，這種模式將 API 設計的責任推到了伺服器端，在 View 和 Model 之間保持了最小的契約。

Action 作為純函式，能夠跨 Model 重用，只要某個 Model 能夠接受 Action 所對應的輸出即可。我們可以期望 Action 庫、主題（狀態表述）甚至 Model 能夠繁榮發展起來，因為它們現在能夠獨立地進行組合。

藉助 SAM 模式，微服務能夠非常自然地支撐 Model。像 Hivepod.io 這樣的框架能夠插入進來，就像它本來就在這層似得。

最為重要的是，這種模式像 React 一樣，不需要任何的資料繫結或模板。

隨著時間的推移，我希望能夠推動瀏覽器永久新增虛擬 DOM 的特性，新的狀態表述能夠通過專有 API 直接進行處理。

我發現這個旅程將會帶來一定的革新性：在過去的幾十年中，物件導向似乎無處不在，但它已經一去不返了。我現在只能按照反應型和函式式來進行思考。我藉助 SAM 所構建的東西及其構建速度都是前所未有的。另外，我能夠關注於 API 和服務的設計，它們不再遵循由前端決定的模式。

老司機介紹

Jean-Jacques Dubray 是 xgen.io 和 gliiph 的創立者。在過去的 15 年中，他一直致力於構建面向服務的架構和 API 平臺。他曾經是 HRL 的研究人員，在普羅旺斯大學（呂米尼校園）獲取了博士學位，Prolog 語言就是由該學校發明的，同時他是 BOLT 方法學的發明者。