使用WPF+Mvvm開發一年多，期間由於對Mvvm模式的理解不足，遇到了很多問題，也繞了很多彎子；網上提供的Mvvm的示例比較簡單，實際項目中的需求也各種各樣。
不過經過幾個項目，也有了一些對Mvvm模式的理解：
1. Mvvm是什麼，Mvvm是怎麼來的？
Mvvm模式廣泛應用在WPF項目開發中，使用此模式可以把UI和業務邏輯分離開，使UI設計人員和業務邏輯人員能夠分工明確。
Mvvm模式是根據MVP模式來的，可以簡單的說，Mvvm模式就是WPF版的MVP模式。MVP模式，MVC模式，這幾個模式都是爲了抽離出UI邏輯和業務邏輯。
2. 使用Mvvm模式可以參考的主流框架及簡單介紹。
主流開源框架：Simple Mvvm，Mvvm Light和Prism。
Simple Mvvm和Mvvm Light基本一致，都是對Mvvm模式的基礎封裝，並加入了一些不錯的功能，消息傳輸機制，依賴注入等等。開發中小項目推薦使用這兩個的其中一個。
Prism是微軟給出的一個Mvvm框架，不過它的關注點不僅僅是Mvvm模式，我覺得主要是模塊的思想更多一些。大項目的話才推薦使用這個框架，比如一個系統需要分爲N個團隊進行不同模塊的開發，然後再組織成一個系統。
3. 使用Mvvm模式的思想分析問題。
現在有一個功能：用戶填入姓名，年齡，選擇最喜歡的顏色，然後點擊確定按鈕提交。就是這樣簡單的一個調查表。
a.首先設計UI，UI看起來可能是這樣的：
b.根據UI去設計對應的ViewModel層需要那些屬性，數據和命令：
Name:string Age:int FavoriteColor:string Submit:Command
c.在ViewModel層的SubmitCommand命令中，調用Model層的Submit方法進行邏輯處理。Model層看起來可能是這樣的：
public string Name { get; set; } public int Age { get; set; } public string FavoriteColor { get; set; } public void Submit() { ... }
4. 看到的一些對Mvvm模式的看法，覺得不太正確。
a.Code-Behind文件要保證絕對乾淨。
這個說法有些太絕對了，理想狀態下，View層的Code-Behind文件中只有在構造函數中調用初始UI元素的一行代碼及設置View層的DataContext爲對於的ViewModel層。
其實，Code-Behind中還可以些一些UI的邏輯的，比如一些豐富的動畫效果，或者直接設置某個元素的樣式等。
不過，Code-Behind中確實是不可以寫業務邏輯的。
b.ViewModel層不能是Model層的簡單封裝，ViewModel層也不能是View層的簡單映射。ViewModel層和View層要絕對分離，ViewModel層要和View層一樣去面向需求設計。
我覺得這樣做有點太過了。
Mvvm的目的只是爲了UI邏輯和業務邏輯的分離，你說業務邏輯和數據要寫在哪一層呢？沒錯，Model層。
ViewModel層的主要責任是表現邏輯和狀態，即ViewModel層是連接View層和Model層的。Model層的一些業務邏輯的狀態是需要通過ViewModel層暴露給View層來反映給軟件使用者的。
5.我對WPF+Mvvm模式開發的一些經驗。
a.WPF的幾個重要概念要熟練理解和運用：模板，依賴屬性，數據綁定。和Mvvm模式的結合使用，能發揮出很好的效果。
b.團隊中的成員最好能夠對Mvvm模式有統一的理解和認識。
c.Mvvm模式只是一個模式而已，不是有了Mvvm模式就能寫出優美的代碼，涉及到具體的業務邏輯，還是需要你以及你的團隊有足夠強的設計能力。
各位大牛如有不同的觀點可以一起討論下。
