WPF開發工具中有各種各樣的模式，運用這些不同的模式可以為我們創造各種不同的基于圖像處理的功能需求。其中，WPF MVVM是專為WPF打造的模式，也可以說MVVM僅僅是MVC的一個變種，但無論如何，就實踐而言，如果你或你的團隊沒有使用"Binding"的習慣，那么研究MVVM就沒有多大意義。#t#

另外,個人覺得，使用Command以及打造一種合理的簡化的方式去使用Command也與使用Binding一樣重要。

為了解決現實世界中的問題,我們需要將現實世界中的事物加以抽象，然后得到了Domain Object，無論貧血的還是富血的，我們都可以簡單地把他們歸結為"由現實世界抽象出來的模型"，也就是我們的model，也就M-V-VM中的"M"。

但其無法與我們的用戶進行交互，所以，我們需要為其創建一個界面(視圖，View)，該視圖可以與用戶輸入設備進行交互，這很棒，但問題是如何將View與我們的model關聯起來? Binding便可以發揮作用了，比如視圖上的某一個文本框中的文本和Model中的"用戶名"關聯起來，用戶便可以通過操作該文本框來訪問和修改Model的"用戶名"了。

這是極其簡單的情況，但實際編程時我們發現，Model中的屬性(與方法)往往不那么容易與View中的界面控件關聯起來，比如，"類型不匹配": 界面控件所需要的類型與模型中屬性提高的類型不匹配。 "需要額外操作": 模型中的數據需要經過一些額外的處理才能傳給視圖,反之亦然。 此時，我們意識到View似乎需要一個"Helper"類來處理一些額外工作。

這個helper所包含的代碼可以放在除了Model外的很多地方(我們現在不考慮貧血富血之類的爭論)，比如View中，記得自己剛學習窗體程序開發時就是這么干的，將絕大多數處理邏輯放在那個所謂的CodeBehind中。

后來,正如大家在各種設計模式書籍中所看到的一樣,為了將View和Model剝離開來,實現view可替換(比如你可以講自己精心設計的軟件同時運行于窗體程序,Web甚至Mobile上)，便有了MVC。 有了MVC以后似乎就開始滋生M-V-XXX之類的爭論與變種模型，比如MVP以及這里的WPF MVVM,甚至MVP也有著Supervising Controller與Presentation Model兩種方式。

但主要圍繞兩個問題,一是model與view之間的關系，完全隔離的?單向的還是雙向的? 二是這個"XXX"需要完成哪些功能,簡單流程調度?復雜規則處理? OK,這些爭論都沒有關系，是否采用某種模式取決于你的開發所處的環境(比如語言特性,框架特性)以及你的業務特性以及所面臨的主要變化點等等。

但與MVC,MVP所不同的是,WPF MVVM的引入不僅僅是技術上的原因(解除耦合應對變化等老生常談),另外一個很大原因是:軟件團隊開發方式的改變。如果你做過一段時間的WPF項目開發的話,你可能會有比較明顯的感覺:在View層打造上,如何分配程序員和美工的工作。

 以前我們團隊采用的便是"集成模式"，我便兼職了其中的"Integrator"角色。這還不錯。但說實在的,這僅僅是一個在特殊情況下不得已而為之的暫時方案,所以我們付出了很大的努力開始轉向"收割模式"了,要轉向這個模式,至少需要兩個基本條件:

(1)你擁有能夠熟練運用Blend等工具能為程序員輸出XAML的美工，他專注于純粹的UI/UE，另外他還必須具有一定的"程序員"思維。以便輸出的東西能很好地作為程序的一部分而運轉起來,而不是僅僅"看上去"是那樣的。

(2)你需要能夠脫離View層但仍能編寫出高質量代碼的程序員。

幸運的是，我們在努力創造條件1,并取得了很好的效果。(你可以招一個具有Flash腳本編寫經驗的并且有極大的學習熱情的美工人員，并對他進行Blend的相關培訓)。 而WPF MVVM模式為我們實現第二個條件提供了極大的便利。 為什么MVC/MVP模式不行而MVVM可以呢? 很簡單，在MVC和MVP模式中，View層都具有很多代碼邏輯，開發View層的是程序員，雖然UI/UE團隊會做很多工作，但這個層的"實現者"仍然是程序員。

在以前的開發中,其工作得很好，而在WPF開發中程序員對View層的展現顯得力不從心了,美工(指符合上面條件1的美工)雖然很擅長，但他會說"可惜我不會程序"。于是，我們需要一種方式將View層的代碼邏輯抽取出來,并View層很純粹以便完全讓美工去打造它。相應地，需要將View層的相應邏輯抽取到一個代碼層上,以便讓程序員專注在這里。

回想一下，我們只所以要在View(Xaml)背后寫一些代碼(C#)，無非是想傳遞一些數據以及傳遞數據時的數據的處理或在用戶與界面控件進行交互時執行一些操作，最簡單的例子是在MVC中當界面發生交互時View去調用Controler中的某個方法，以便將該操作的相應"指示"傳遞到"后臺"去。 在以前的技術中，這樣的"銜接性"的代碼是必須的。

而在WPF中，則可以通過另外的技術來進行層與層之間的"銜接"，這就是"Binding" 和"Command"，以及稍后我們會提到的"AttachBehavior"。 通過Binding，我們可以實現數據的傳遞; 通過Command，我們可以實現操作的調用。(AttachBehavior的作用稍后再談)。 Binding和Command是可以寫在XAML中的，這樣看來XAML后面對于的CS文件可以被完全拋棄或不予理會了。 這樣的XAML文件正是美工所需要的。

而這些對于Binding以及Command的定義描述以及其他相關信息的代碼應該放在那里呢，當然不是View，更不是Model，是"ViewModel"。 ViewModel是為這個View所量身定制的，它包含了Binding是所需的相關信息,比如Converter以及為View的Binding提供DataContext，它包含了Command的定義以便View層可以直接使用，另外,它還是一個變種的Controler，它得負責業務流程的調度。

于是，正如"時勢造英雄"所言，WPF MVVM就誕生了。