MVC已死，該是用MOVE的時候了

學習新技術，希望與博友共勉之

提升總結和翻譯

記錄自己學習的過程

//可以略過部分

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是一種更好用的新工具。

 //坐等吐槽....

本文轉自 Ron Ngai 部落格園部落格，原文連結：http://www.cnblogs.com/rond/archive/2012/07/06/2580095.html  ，如需轉載請自行聯系原作者