MVVM的概念已經在腦子里滲透了一段時間，也試著使用了一段時間，就我個人理解，MVVM所倡導的應該是解耦UI跟數據打交道的那一部分，而純UI的還是寫在CodeBehind里。MVVM是以綁定（綁定數據、綁定命令）來驅動的，脫離了綁定的UI元素就沒必要使用MVVM。假設一個窗口里的button作用是關掉這個窗體，如果這樣一個動作都要綁到命令里去，簡直就是自找麻煩。

　　開始MVVM之旅的第一站是實現INotifyPropertyChanged的接口的問題，雖然可以使用Prism或者MVVMLight，但是這個原理還是要懂一點的。在M里實現INotifyPropertyChanged還是在VM里實現，to be or not to be，糾結了很久。

　　VM其實就是V的建模，是model for view的意思，所有創建VM的時候是根據V來創建的，為V準備綁定的數據，提供暴露的屬性，綁定的命令等。那么問題就來了，要使數據有通知UI的能力，就必須實現INotifyPropertyChanged，如果在M里實現，寫M的人就有意見了：我的M只管我自己的邏輯，不管你UI的東東。并且，在M里實現它，如果VM里沒有相應的代理屬性來獲取，UI就得直接綁到“屬性的屬性”，看起來V已經直接聯系到M了。好吧，那么就在VM里實現它，這樣看起來似乎清爽了，需要的話就搞M的代理屬性，在代理屬性里通知UI，UI直接來綁VM，這似乎更合理一點。

　　第二站，VM該面向什么。我上面說了一種，所有的VM都是根據V來創建，也有人說VM的創建應該面向業務，可以降低復雜性，增大復用性，因為面向M必定增加復雜性，面向V肯定降低復用性，而面向業務就能取中間的效果。目前我還是面向V，首先是因為這樣簡單，其次是，面向業務是可以降低復雜，增加復用，可是也是有代價的，你必須了解對項目、需求、甚至設計都十分了解，這樣才能抽象出復用性很強的業務，在我沒達到那個水平之前，還是老實一點。再者，沒使用MVVM之前，我也沒見到哪個V的CodeBehind要去用別人的CodeBehind，在我看來，VM只是把V的CodeBehind剝離出來了而已。當然，有些VM是顯而易見可以復用的，那就沒必要再建多建VM了，心里上感覺，內存是是有限的，能省就省吧。

　 第三站，數據的更新時機。一般binding使用了twoway模式，就會及時更新了，UI有什么動作，數據也跟著變，可是有時候也有這樣的需求，UI需要顯示地更新數據，而不是自動更新。比如我有一個窗體，上面一個文本框綁定了一個數據，和一個按鈕用來關閉窗體。當我改變了文本框的內容的時候，我希望我點了關閉按鈕的時候才去更新文本框綁定的數據，而不是文本框改變直接立即更新，有一種方案是UpdateSourceTrigger=Explicit，然后在后臺里得到BindingExpression，再執行UpdateSource(),這樣就能顯示更新數據了，這樣也有個小問題，UpdateSource方法是要通過控件的BindingExpression去執行的，那就得首先找到這個控件，這是很令人抓狂的，如果一個gridview里有一列是1000個checkbox，我得找到這1000個checkbox，然后再去更新，直接調用gridview的UpdateSource是不會更新里里面的控件的，不知道微軟是沒注意到，還是里面另有玄機我沒參透 。

轉載于:https://www.cnblogs.com/zoexia/archive/2013/06/03/3114983.html

總結

以上是生活随笔為你收集整理的MVVM之旅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。