Web前端開發，爲什麼選擇MVVM而非MVC

在Web中充斥着所謂的MVC框架，而在我看來，由於一些關鍵性的技術緣由，MVC在Web前端開發中根本沒法使用(對的，是沒法，而不是不應) 。

在MVC原始報告中指出：

view永遠不會知道用戶輸入，好比鼠標操做和按鍵。

很顯然，在Web前端，你沒法作到這一點，由於Web的程序中，用戶的輸入必須經過監聽窗口、文檔和元素上的事件來得到。——而這些東西經常被認爲是View。

因而一些奇怪的認識誕生了，好比認爲Controller應該是View操做Model的中介。

John Gossman（WPF的架構師）在他的文章中提到，

Model/View/ViewModel中的View表示可見元素，按鈕，窗體，圖形或者GUI中更復雜的控件，它會對快捷鍵進行編碼，而且控件自身會管理跟輸入設備的交互——這在MVC中本該是Controller負責的（現代GUI環境中發生在Controller上的事情是很長的題外話……我傾向於認爲它只是隱藏到後臺了，它仍然存在，可是咱們不須要像是1979年那樣考慮那麼多事情了）

MVC這樣的結構的正確性在於，任何界面都須要面對一個用戶，而Controller 「是用戶和系統之間的連接」。在經典MVC中，Controller要作的事情多數是派發用戶輸入給不一樣的View，而且在必要的時候從View中獲取Editor來更改Model，而Web以及絕大多數如今的UI系統中，Controller的職責已經被系統實現了。下面的圖片說明了這樣的演進過程：

總而言之，對於MVC

• 爲1979年的SmallTalk設計 
• 界面和程序都由同一種語言編寫
• 用戶輸入徹底由程序編寫者來處理
• View是單純用於顯示

對於MVVM

• 爲2005年的WPF設計 
• 界面多使用標記語言，程序則使用編程語言
• 用戶輸入通過UI系統底層處理和分發，多數以事件的形式被用戶程序所知
• View具備獨立性，可以管理部分用戶輸入而且自行反應（它們經常被稱做控件，而非視圖）

做爲一個Web開發者，在兩者之間作出何種選擇是顯而易見的。