- 學習新技術，希望與博友共勉之
- 提升總結和翻譯
- 記錄自己學習的過程
MVC模式是一種不一般的設想。MVC模式包含有封裝業務邏輯和數據處理的數據模型層（Models），顯示用戶界面的視圖層（Views）和控制和連接模型層和視圖層的控制層（Controllers）。
什么？
Conrad Irwin很肯定他不是第一個發現下面這一點的。當你不清楚在那里寫代碼的時候，MVC會帶來讓你將過多的代碼寫在控制層（Controllers）的問題。
為了解決這個問題，我采用一種新的模式：MOVE。模型層（Models），操作層（Operations），視圖層（Views）和事件層（Events）。
概念
圖片顯示了MOVE模式的基本結構，下面是對每個層的解釋：
- 模型層（Models）封裝應用程序所知道的一切。
- 操作層（Operations）封裝應用程序所作的一切。
- 視圖層（Views）完成用戶與應用程序的交互。
- 事件層（Events）被用於安全地連接組件。
模型層（Models）
創建一個原型模型即一個“user”對象。它至少有一個用戶名（email），或許還有一個名字（name）和電話號碼（number）。
在一個MOVE模型應用程序中，模型層（Models）只用於包裝知識。意思是，它包含讓你驗證“這是否是用戶密碼？”的函數來讓獲取（getters）和設置（setters）屬性值。但是它不包含讓你保存它們到數據庫或者上傳到一個外部API的函數。這是操作層（Operations）的事情。
操作層（Operations）
一個基本的操作例子就是讓用戶登錄。這分兩個字操作來完整。第一，獲取用戶的用戶名（email）和密碼（password）。第二，加載調用從數據庫查詢出數據而設置好的的“user”模型，驗證密碼是否正確。
操作層（Operations）是MOVE模型世界的執行者。它的職責是設置的模型層（Models），在正確的時間調用顯示正確的視圖層（Views）以及相應用戶觸發引起的事件層（Events）。在一個好的應用程序中，每一個子操作都可以在父操作下獨立運行。這也是為什么圖表中事件層中流往上走和改變往下走。
用操作層（Operations）這種方式讓人驚訝之處在於，當程序重啟開始的時候，你的整個應用程序可以視為是一個操作（Operation）。根據需要被分為多個子操作。同時，每一個字操作可以並行存在運行。另外，當所有字操作運行完成時，程序退出。
視圖層（Views）
登錄界面是一個顯示若干文本框給用戶的一個視圖（View）。當用戶點擊“Login”按鈕，視圖（View）會產生一個包含用戶輸入用戶名和密碼的“loginAttempt”的事件（event）。
用戶能看到和能交互的所有事情應該被建設為一個視圖（view）。它們不但不顯示應用程序在不明方式下的狀態，而且將用戶產生的交互簡化為有意義的事件（Events）。重要的是，視圖（views）不會直接改變模型（models），它們簡單地觸發事件到操作，然后等待由模型觸發事件所引起的改變。
事件層（Events）
事件“loginAttempt”是由於用戶點擊登錄的視圖觸發的。另外，當登錄操作完成，“currentUser”模型會觸發事件，將模型引起的改變通知應用程序。監聽事件是讓MOVE模式（和MVC模式）的一種逆控制。這種控制是在模型沒有直接意識到視圖在更新的時候，你允許模型更新視圖。這是一種高度抽象的技術。這種技術允許組件相互存在而又相互不影響。
為什么該是時候了？
Conrad Irwin不希望被誤解成這表示MVC已死。在過去的十幾年中，MVC在大型結構的應用程序當中確實獲取了令人難以置信的成功。它出現十幾年了，但是，新的編程技術已經越來越流行。沒有它的自閉性（或者匿名塊），事件綁定變得非常乏味。沒有它的延期和承諾，這種用各自權限處理當對象看的各自層次操作的思想不會有什么意義。
再次重申：MVC很棒，但是這是幾十年前設計的老技術了。MOVE是一種更好用的新工具。
備注：Conrad Irwin不是唯一開始思考這種模式的人。如果你喜歡MOVE，你可以查看objectify和interactions文章。里面除了闡述MVC程序之外還試圖解釋了MOVE的好處。如果你有其他的連接應該出現在這里，你可以告訴我。
再次備注：這篇文章被翻譯為日語不止兩次：d.hatena.ne.jp 還有 blog.neo.jp. 謝謝！
//坐等吐槽....
文章原文來自“MVC is dead, it's time to MOVE on.”。可能存在不准確翻譯，推薦閱讀“MVC模式已死？何不試試MOVE”。