MVC 模式在編程中的應用，是一個很了不起的主意。“數據模型（Model）”可以封裝與應用程序的業務邏輯相關的數據及對數據的處理方法；“視圖層（View）”能夠實現數據有目的的顯示；“控制器（Controller）”能夠在不同層面間起到組織作用，對應用程序的流程進行控制。
不過，可能你在使用這種三層架構模式的過程中會逐漸迷惑。因爲有很多代碼你不知道把它放哪，就只好把它放到控制層，最後發現在控制層中塞了太多的代碼。
LinkedIn 的軟件工程師 Conrad Irwin 也遇到同樣的問題，於是他開始使用另一種模式：MOVE，即 Models（模型）、Operations（操作）、Views（視圖）、Events（事件）。近日 Conrad Irwin 在個人博客上分享了關於這種模式的一些觀點。
概述
Irwin 結合上圖對 MOVE 模式先作了簡單定義：
Models，封裝該應用程序中知道的一切；
Operations，封裝該應用程序要做的一切；
Views，幫助用戶與應用程序完成交互；
Events，用於安全地連接所有這些組件。
爲了避免意大利麪條式的代碼，圖中標示出了對哪種類型的對象進行操作是允許的。例如，視圖允許監聽由模型產生的事件；操作允許修改模型，但模型不應涉及視圖或操作。
Models（模型）
這裏以一個“User”對象爲原型，它至少應用有一個 Email 地址，也可能有用戶名和電話號碼。
在一個 MOVE 模式的 Models 中只包裝知識。這意味着除了 Get 和 Set 功能，它們可以包含檢查用戶密碼是否正確這樣的方法，但不會包含把密碼保存到數據庫或傳遞給外部 API 這樣的功能，因爲後面這些工作將由 Operations 來完成。
Operations（操作）
對應用程序來說，一個常見的操作是用戶登陸。這實際上是由兩個子操作組成：首先從用戶那裏獲得郵件地址和密碼，然後從數據庫載入“user”模型並檢查密碼是否匹配。
Operations 是 MOVE 模式中的行動者。它負責修改模型，在正確的時間顯示正確的視圖，以及響應由用戶交互引發的事件。在一個分解良好的應用程序中，每個子操作都可以獨立運行。
採用這種方式的操作有一點很令人振奮，即程序啓動後，整個應用本身就可以被當作一個 Operations。它會根據需要生成儘可能多的子操作，其中每個子操作都並行地運行。當所有子操作都完成時，程序也便退出。
Views（視圖）
登陸頁面即是一個視圖，它負責顯示一些文本框給用戶。當用戶點擊“登陸”按鈕時，視圖將產生一個“loginAttempt”事件，其中包含用戶輸入的用戶名和密碼。
用戶能夠看到的內容，以及能感受到的互動都由視圖提供支持。它們會以一種用戶能理解的形式呈現應用反饋，同時還能將簡單的用戶交互轉換成有意義的事件。更重要的是視圖不會直接改變模型，它們只是向 Operations 發起事件，然後通過監聽等待由模型發起的事件。
Events（事件）
當用戶登陸時，視圖會發起“loginAttempt”事件。在登陸操作完成後，“currentUser”模型會發起一個事件通知應用登陸狀態已改變。
事件監聽讓 MOVE（及 MVC）實現控制反轉，允許模型更新視圖。這是一種強大的抽象技巧，允許組件互不干擾地耦合在一起。
爲什麼是現在？
當然，Conrad Irwin 並不想被人認爲自己是在暗示 MVC 模式很差，這種大型應用程序架構在過去的幾十年裏確實非常成功。不過幾十年後的今天，新的編程技術已經變得越來越流行，所以你也會在使用過程中逐漸產生一些疑惑。
MVC 模式確實很了不起，但它畢竟是幾十年前爲老的技術而設計。MOVE 模式是在其基礎上的升級，讓你可以更好地利用當前已有的新工具。