MVVM優於MVC的好處

Question

最后開始做一些Silverlight開發，我遇到了MVVM。 我熟悉MVC和我正在閱讀的文章說因為XAML，MVC無法解決。 沒有太多的XAML經驗是我沒有明白這一點的原因。

有人可以解釋為什么MVC不適合以及為什么MVVM更適合Silverlight開發？

謝謝JD

Answer 1

它是一個非常細微的區別，我可以通過比較ASP.NET中的MVC和WPF中的MVVM來解釋。

在ASP.NET MVC中，請求來自Web服務器，由Controller直接處理。 Controller確定適當的視圖並使用模型填充它。 然后，Controller將這些實例發布到底層系統，該系統將結果呈現給客戶端。 您可以看到Controller是第一個也是最后一個。

在MVVM中，UI（視圖）面向用戶並直接獲取用戶輸入。 在View中，ViewModel中的命令（View的DataContext）由此活動觸發。 控制流向ViewModel，ViewModel解釋View發送的內容並准備其模型。 控制流回View后，它會根據模型中的更改自行更新。 如果需要新的View，ViewModel會將此與NavigationService（或您的應用程序使用的任何導航方法）進行通信，這是Window或Frame-UI組件的范圍。 您可以看到ViewModel不是第一個也是最后一個行為; View比MVC扮演更重要的角色。

WPF / Silverlight的體系結構是事情以這種方式完成的原因。 控制器無法控制/替換命令，綁定和導航基礎結構; 它們與UI緊密集成。 因此，Controller必須位於View下方，並采取更為被動的角色。

Answer 2

MVVM的設計主要是因為XAML並且使數據綁定更簡單，它與MVP非常相似。 主要的好處是操作用戶界面的簡單方法（ViewModel或Presenter處理該任務，而不是模型必須在Controller操縱后向View發送事件）。

我遇到的最好的兩篇文章幫助我理解了原則是MVC vs MVP vs MVVM和MVVM for Tarded Folks Like Me 或 MVVM及其對我意味着什么

Answer 3

去耦組件

在MVC中，組件之間存在三角關系。 即：Controller擁有View和Model。 View依賴於Model的定義。 模型需要滿足View的要求。 想想Hub（控制器）和輻條架構（視圖和模型）

在MVVM中，考慮到每個組件的三角形變平，只知道鏈中的另一個。 那就是：View-> ViewModel-> Model

模型不知道堆棧中的任何東西。 ViewModel只知道模型View只知道View模型 - 它不知道Model。

為什么這很重要？

這是原始問題的核心。

主要目的是進一步抽象您的架構。 這通常會導致更多代碼，但對象之間的聯系點更少。 較少的聯系點很重要，因為這會導致更敏捷的代碼。 A類與B類的耦合/接觸越多，A類變化的影響就越大。 減少變更的影響是良好架構的關鍵優勢之一。

要完全理解這一點，思考組件真正代表什么是有幫助的。 什么是視圖，控制器，ViewModel或模型？ 它們是字面定義，還是更抽象的概念？

根據我的經驗，將模型視為一個處理數據構造和持久性的類/對象集群更為有益。 它不僅僅是一個具有屬性的普通舊對象。 它是一個執行數據提取，數據保存，構建普通舊對象的工廠的類。 它是一個Facade層，為數據提供了清晰的API。 該外觀層是否應直接從View引用？

在我看來，它不應該。 在MVC中，答案也是“不”。 Controller從模型中獲取數據。 在這方面，MVC和MVVM實現了相同的目標。 兩種體系結構不同的地方是數據和視圖的鏈接方式。

與模型一樣，View可以是一個類的集合，它們彼此協調，呈現一個表示視圖。 對於移動平台（iOS上的View Controller，Android上的Activity），這可能包含View Controller + View。 在很多情況下，您需要一個類將視圖文檔加載到內存中並更新視圖屬性。 這里有很多工作要做。 在MVC中，Controller很快就變成了“廚房接收器”類 - 一種與當前用戶環境相關的任何傾銷場。

當您在應用程序中將數十個潛在視圖相乘時，您最終會在后端模型代碼和前端View代碼之間產生很多深度依賴。 對於大型Controller類，這些依賴關系並不是很明顯。

展平您的依賴項

MVVM消除了依賴關系。 這創造了焦點。 什么是焦點？ 能夠處理單個功能而不會分散所有其他依賴項。 現在，您可以開始在以前認為不可測試的代碼上編寫單元測試。

視圖模型充當視圖和模型之間的外觀。 View Model滿足View的需求 - 從技術上講，View應該擁有View Model。 如果View需要來自多個源的數據，則View Model會將單獨數據源的組合封裝到單個統一的非規范化對象中。 如果視圖需要回調到模型或其他目標，則視圖模型提供掛鈎並路由相應的調用。

考慮一下網絡配線架的工作原理。 乍一看，這似乎是多余的 - 為什么不簡單地將您的以太網從A點連接到B點。但是根據經驗，您將了解補丁面板為您提供了一個關鍵的抽象，允許您更改Point的路徑B不影響A點。這是您的View Model正在執行的操作。

現在您在View和Model之間有一個干凈的抽象，結果應該是您的View / Controller只關注表示。 這意味着它不應該處理本地化或格式化 - 它獲取數據並呈現數據。 您的視圖模型是進行這類預覽數據按摩的理想場所。 假設您需要根據條件過濾數據。 同樣，視圖模型可以了解模型數據（您的視圖不是），並且是放置此類代碼的好地方。

一旦以這種方式開始組織應用程序需求，您的View / Controller代碼就會變得更清晰，當需要更改某些內容時，其含義會更明顯，從而導致更少的錯誤。

可測性

關於可測試性的最后一點注意事項：通過展平依賴關系，可以更輕松地將模擬依賴項注入到測試中。 它使測試更容易，更簡潔。 您的視圖模型將成為可以定義明確測試用例的內容。

Answer 4

我認為另一個好處是學習曲線。 由於前端技術中的大多數開發人員都使用MVVM類型的編碼風格，因此他們更容易采用與控制器模型相同的方式，他們需要將每個請求從視圖傳遞到控制器並讓它與模型進行通信。

Answer 5

我認為這個想法是MVVM比MVC 更適合XAML。 說MVC'不適合'有點誇張。

為什么MVVM更好？ 主要是因為XAML中的數據綁定和命令綁定非常出色。 看到這篇文章 。