2010-12-15 63 views
2

當我學習MVVM模式時,我遇到了一個問題。我正在構建一個示例筆記應用程序。在這個應用程序中,您可以看到NotesView的註釋列表。 NotesView的DataContext是NotesModelView。一組模型的MVVM模型?

我的問題是應該NotesModelView包含一個NoteModel或NoteModelView(它包含一個NoteModel)的集合?

回答

1

我傾向於將所有模型類包裝到視圖模型中,所以我的一般答案是包含NoteModelNoteViewModel的集合。

但我也是DRY principle的粉絲,所以在那些ViewModel根本沒有任何好處的情況下(例如我不需要重新格式化數據,我不需要改變通知,我不介意將原始模型暴露給視圖)我有時會違反這條規則。

既然您正在嘗試學習MVVM,那麼對於這種特殊情況我的建議是與一系列視圖模型一起去。這會讓你更好地理解MVVM,並在以後的應用程序中面對這個問題時幫助你做出這些區分。

+0

感謝您的建議 - 我仍然在攀登那種陡峭的學習曲線,所以我想確保在我之前正確理解模式開始偏離它。 – Jackson 2010-12-15 16:33:53

+0

沒問題..並隨意投票所有答案,你會發現有幫助;-) – 2010-12-15 20:16:19

1

好的,你的命名有點混亂,我會選擇一個更乾淨的命名標準!人們通常使用'View'來後綴視圖,並使用'ViewModel'查看模型。

所以在你的情況下,有一個NotesView的DataContext是一個NotesViewModel。在你的NotesViewModel上,你應該有一個Notes的集合(或者NotesModel,如果你想這樣做的話)。您的NotesViewModel不應包含NotesViewModel的集合,因爲這可能不需要,因爲您可能只想在NotesView中顯示Note數據。

+0

對不起,令人困惑的命名,休息asssured它不是我在應用程序中使用的命名風格。我只是認爲,如果我也用「模型」來修飾模型,會更容易理解。 – Jackson 2010-12-15 16:32:47

2

我總是將我的模型包裝在視圖模型中。這樣,用戶所做的任何更改只會應用於視圖模型,而不會應用於底層模型,直到用戶想要提交這些更改(例如通過「保存」按鈕),並且如果用戶不想提交,您可以扔掉視圖模型,並從頭開始,而不改變你的模型。這在處理數據庫實體/對象時尤爲重要,因爲直接對實體所做的更改可能會使回滾變得痛苦(至少如果您使用的是實體框架)

某些情況下,「提交」是隱含的上述不適用,但我仍然認爲使用視圖模型是一種很好的做法,因爲它還允許您單元測試您的業務邏輯。 MVVM背後的主要動機是可維護性和良好的單元測試是實現這一目標的一種方式。

+0

謝謝 - 我沒有想到這個! – Jackson 2010-12-15 16:33:09

0

在你的例子中,你應該注意 - 作爲一個模型,你應該定義Note的ObservableCollection鍵入列表,它將代表你的模型列表。 此列表將在您的ViewModel中,並且您可以將其綁定到您項目中的任何視圖