MVVM，我應該把模型或視圖模型（控制器）的邏輯

我是MVVM的新手，現在正在做一個Silverlight項目的MVVM重構工作，假設它是一本書購物應用程序。MVVM，我應該把模型或視圖模型（控制器）的邏輯

該視圖是書籍列表，我將書籍的標題綁定到ViewModel。所以我有一個視圖模型public string Title { get; set; }，也是一個public string Title { get; set; }在模型（是嗎？）

現在我希望把事件處理程序來更新書名，我應該把事件處理程序的視圖模型或模型？以及該模型用於什麼？

來源

2011-10-17 demaxSH

簡而言之，模型是「真正的」底層數據模型 - 包含應用程序可能需要的書單的所有信息，能夠從數據庫中獲取和設置數據。

ViewModel是一個主要爲您的View提供數據綁定的對象。它可能是模型的一個子集，或者它可能將來自多個模型的屬性組合到單個對象中。它應該包含必要和充分的屬性以允許View執行其工作。

如果事件處理程序與View相關，則它屬於ViewModel。如果它符合您的目的，您可以嘗試使用命令模式（請參閱Custom WPF command pattern example）。

來源

2011-10-17 02:27:20

在我看來「無論」......將控制器類添加到MVVM的混合。

將控制器代碼放入視圖模型的問題是，這使得它們更難以獨立測試。在很多方面，我認爲這跟代碼背後一樣糟糕。

在我看來，每個人都認爲MVVM沒有控制器，因爲他們忽略了C. MVVM實際上是MVC的一個變體，「它只是添加ViewModels」。

也許它應該被稱爲MVCVM呢？

ViewModels僅用於從視圖中卸載「GUI」代碼幷包含任何用於綁定的數據。 ViewModels不應該做任何處理。一個好的測試是你的ViewModel可以通過自動化的單元測試進行測試，並且不依賴於數據源等等。他們不應該知道數據實際來自哪裏（或者誰正在顯示它）。

雖然可以忽略/避免，但控制器應該負責決定要顯示的數據模型以及在哪些視圖中。 ViewModel是模型（MVVM中的M）和視圖之間的橋樑。這允許更簡單的「分離」XAML創作。

我們在所有最近的項目中成功使用的模式是僅在模塊中註冊控制器，並在啓動時對它們進行初始化。這些控制器非常輕薄，只需要在應用程序的生命週期中監聽或發送消息。在他們的初始化方法中，他們然後註冊他們需要擁有的任何東西（視圖和視圖模型等）。這種輕量級的純邏輯內存模式也適用於更薄的應用程序（例如更適合WP7）。

我們遵循的基本規則是：

控制器使基於事件
控制器獲取數據，並將其放置在適當的視圖模型屬性
控制器設置視圖模型的ICommand的屬性，以攔截決定事件
控制器使視圖出現（如果不是暗示其他地方）
查看模型是「愚蠢的」。他們認爲數據綁定，並沒有別的
瀏覽知道他們顯示的數據有一定的形狀，但不知道來自何處

最後兩點是你永遠不應該打破那些或分離關注窗口。

來源

2011-10-17 09:27:14

對於是否在ViewModel中放置事件處理或邏輯可能存在爭議，但現在我想知道模型專用的是什麼？它不應該有邏輯權利？ – demaxSH

該模型包含業務數據（通常是業務邏輯，但從來沒有UI或應用邏輯）。它的模型不應該知道它是如何被消耗的。 –

MVVM，我應該把模型或視圖模型（控制器）的邏輯

回答

相關問題