摘要：由于控件與業務邏輯之間的緊耦合，相應帶來的問題就是變更的代價增大，以及難以編寫針對性的單元測試。這些東西的組合提供了到譯者注視圖模型后面統一簡稱之間的連接方式。的單元測試可以完全模擬在上用的那些功能。

原文：https://github.com/kuitos/kui...
全部文章：https://github.com/kuitos/kui...

原文：The MVVM Pattern

MVVM 模式跟 Silverlight 這類 XAML 應用平臺是天生合拍的。這是因為 MVVM 模式利用了Silverlight 的一些特殊能力，比如說 數據綁定，命令，行為等。MVVM 跟其他一些將表現及UI布局 與展示層邏輯的職責進行分離的模式很相似；如果你對 MVC 模式熟悉的話，你會發現它與 MVVM 之間存在很多相似的概念。

譯者注：XAML(Extensible Application Markup Language)是微軟為構建GUI程序而創建的一種標記語言，你可以將它等同于 web 體系中 HTML。以下譯文中，web 開發者可以將 XAML 統一代入為 HTML。Silverlight 則是微軟開發的一個 富互聯網應用(Rich Internet Application) 開發平臺。

諸如 Windows Forms，WPF，Silverlight 以及 Windows Phone 這類開發技術都提供了一個默認的體驗，那就是它可以讓開發者從工具箱中拖拽控件到設計面板，然后在代碼文件中編寫一定格式的代碼就能完成整個開發。但是隨著這類應用的增長規模及作用范圍的變化，復雜的維護性問題就會隨之而來。由于 UI控件 與 業務邏輯 之間的緊耦合，相應帶來的問題就是 UI 變更的代價增大，以及難以編寫針對性的單元測試。

使用 MVVM 模式來實現應用的主要動機有以下幾點：

它提供了一系列分離的概念。緊耦合，難變化，脆弱的代碼導致了各種各樣的長期維護的問題，最后導致了客戶對交付的軟件較低的滿意度。在應用邏輯及 UI 之間進行干凈的分離將會讓應用更容易測試，維護以及拓展。它提高了代碼的重用性同時使得 開發-設計 的工作流變為可能。

它與 XAML 平臺是天生合拍的。MVVM 模式的關鍵推動力來自于 Silverlight 平臺豐富的數據綁定技術棧及一些依賴屬性。這些東西的組合提供了 UI 到 VM(譯者注：view model 視圖模型后面統一簡稱 VM) 之間的連接方式。

它使得 開發-設計 的工作流成為可能。當 UI XAML 不是與代碼緊耦合時，設計師們就很容易去自由的發揮他們的創造力，從而做出一個更優秀的產品。(譯者：簡單來說就是 視圖層 跟 M/VM 層的開發可以是正交的。)

它增強了應用的可測試性。將 UI 邏輯轉移到一個可以獨立實例化的類中，可以讓單元測試的編寫更加容易。(譯者：這一點其實非常重要)

Model-View-ViewModel 的模式可以用到所有的 XAML 平臺上。它的意圖是在 UI 控件和它們的邏輯之間進行一個純凈的概念分離。

MVVM 模式中有三個核心的組件：model(模型)，view(視圖) 以及 view-model(視圖模型)(譯者注：為保證交流中術語的一致性，model、view、view-model后面均不作翻譯)，它們彼此間扮演一個截然不同的角色。下面的插圖展示了這三個組件之間的關系：

每個組件之間都是相互解耦的，這也使得：

組件可以被交換

內部實現可以在不影響其他組件的情況下修改

組件可以獨立的運作

隔離的單元測試

除了理解這三個組件的職責，理解組件之間是如何交互的也同樣重要。在最高的層級上，view 能感知到 view-model，view-model 能感知到 model，但是 model 并不會察覺到 view-model 的存在，同樣的，view-model 也察覺不到 view。

view-model 將 model 類 與 view 隔離開來，這也使得 model 可以獨立于 view 進行演化。

view 的職責是用來定義 結構、布局，及用戶在屏幕上看到的外觀表現。理想情況下，view 僅通過 XAML 定義，以及一些有限的不包含業務邏輯的代碼。

在一個 Windows Phone 應用中，view 通常是一個頁面。除此之外，一個 view 也可以是一個父 view 的子組件，或者一個 ItemsControl 中的 DataTemplate對象。

一個 view 可以有自己的 view-model，或者繼承自父級 view 的 view-model。視圖通過綁定，或者調用 view-model 上的方法來獲取數據。在運行期間，UI 控件將會響應 view-model 屬性觸發的變化通知，從而改變 view。

有一些 view 上的交互會觸發 view-model 上的代碼執行，比如說按鈕點擊或者選項選中事件。如果這個控件是一個命令源，這個控件的 Command 屬性可以在 view-model 上綁定成一個 ICommand 屬性。當這個控件的命令被調用，view-model 上相應的代碼就會被執行。除了命令，行為也能被附加到 view 的一個對象中，然后監聽命令調用及事件觸發。作為回應，這個行為之后可以調用 view-mode 上的 ICommand 或者方法。(譯者：web 領域里這些就是指的模板上的事件綁定語法，通常由框架提供)

model 在 MVVM 中是應用的域模型(domain model)實現，它包含數據模型以及相應的業務和校驗邏輯。model 對象的例子包括，數據倉庫(repositories)，業務對象，數據轉換對象(DTOs)，POCO對象，以及生成的實體及代理對象。

譯者：一個 model 應該包含基本的模型數據、基本的業務邏輯、業務規則、數據轉換、依賴校驗邏輯等。這里要提到的一個概念就是，域模型分為兩個類型，一類是貧血的(Anemic domain model)，一類是非貧血的(non-anemic)。貧血的域模型只包含基礎的數據信息，而不含有其他數據校驗、業務規則等邏輯，它更像是一種數據庫結構在代碼層面的還原。在貧血域模型設計中，業務邏輯通常作為一個獨立的代碼部分，用來轉換模型對象的狀態，且各個處理之間可以組合嵌套（用過Redux的同學有沒有覺得很熟悉的感覺？）。在面向對象設計領域，這通常被視為一個反模式。（OO與FP之間的沖突）

view-mode 作為 view 和 model 的中間人，它的職責是用于處理 view 的邏輯。通常情況下，view-model 與 model 之間的交互是通過調用 model 類中的方法來完成的。之后 view-model 依據 model 中的數據提供一種方便 view 使用的格式。view-model 從 model 中獲取數據然后使其對 view 可用的同時，為了讓 view 操作起來更簡單，可能會通過一些方式做數據格式轉換。view-model 還提供了一些命令的實現讓應用的用戶可以在 view 中使用。比如說，當用戶點擊了 UI 中的一個 button，這個動作可以觸發 view-model 中的一個命令。view-model 同樣有職責去定義一些某些方面會影響 view 展示的邏輯狀態的變化，比如說一個表明一些操作是掛起的狀態。

為了讓 view-model 參與到與 view 的雙向數據綁定當中，它的屬性必須觸發 PropertyChanged 事件。

(譯者注：后面這兩段是基于 .NET 平臺的具體代碼實踐，換算到 web 領域，基本上說的就是在 VM 中監聽數據變化，然后做出對應的反應。)

View-model 通過實現 INotifyPropertyChanged 接口以及屬性變化時觸發的 PropertyChanged 事件來滿足這個需求。當屬性發生變更時，監聽者可以適當做回應。

對于集合而言，相應的提供了視圖友好的工具System.Collections.ObjectModel.ObservableCollection 。這個工具實現了集合變更通知，從而減輕了開發者自己在集合上實現 INotifyCollectionChanged 接口的負擔。

譯者：這里提到了一個很重要的事情，就是 vm 獲取到 model 中的數據后，可能需要做一些相應的數據格式化，以方便 view 使用。在 ng1.x 及 vue1.x 中，這類操作通常是通過在視圖模板上綁定過濾器語法實現的(ng-bind="model | upperCase")，然而 MVVM 定義中，數據轉換/格式化 的操作本身也是屬于 VM 的一部分。這也是為什么我非常贊同 vue2 中廢除 filter 的一部分原因：Vue 2.0 - Bring back filters please

MVVM 利用了 Silverlight 中的數據綁定能力以及行為和事件觸發器來管理 view 和 view-model 之間的聯系。這些能力將業務代碼需要出現在視圖代碼中必要性變得很低。

有很多用來連接 view-model 和 view 的方法，包括直接的關系以及基于容器的方式。然而，所有的方式共有的一個目標就是，給 view 的 DataContext 屬性分配一個 view-model。

Views 可以與 view models 在獨立代碼文件里建立連接，也可以直接在 view 中。

譯者：這里提到了 silverlight 里的 DataContext，換到 web 領域的 MVVM 框架里我們可以理解成作用域，即框架通過給某個視圖的作用域分配一個 view-model 的方式，來完成 view 和 view-model 的銜接。

一個 view 的代碼可以是在獨立代碼文件中，于此同時 view-model 需要分配成它的 DataContext 屬性。這可以是通過一個簡單的 view 初始化一個新的 view-model 然后分配給它的 DataContext 屬性來完成，也可以通過 view 使用控制反轉(IOC)容器注入一個 view-model 來實現。

但是，在獨立代碼中 連接一個 view-model 到 view 中的做法是不推薦的，它可能給同時使用 VS 及 MSB(Microsoft Expression Blend?) 設計軟件的設計師造成問題。

如果一個 view-model 沒有任何的構造器參數，它可以被當做 view 的 DataContext 來實例化。一個通常的實現方法是使用一個 view-model 定位器。這個資源可以公開應用的 view models 作為屬性，從而使得獨立的 view 可以綁定上去。這種方式意味著應用只有一個類用來連接 view models 到 views。此外，它仍然讓開發者可以自由選擇手動執行 view-model 定位器內的連接，或者使用一個依賴注入容器。

譯者：框架實現指導

MVVM 使得完美的 開發-設計 工作流變為可能，它具備以下優點：

開發期間，工程師和設計師可以更獨立并行的在各自的組件上工作。設計師可以專注于 view，如果他們使用 Expression Blend，他們可以輕松的生成示例數據，而這個時候開發者只需要專注于 view model 和 model 組件。

開發者可以為 view-model 和 model 編寫單元測試，而不用去管 view。view-model 的單元測試可以完全模擬在 view 上用的那些功能。

由于 view 是完全由 XAML 實現的，這也讓應用的 UI 重新設計變得簡單，而且還不用去觸碰到邏輯代碼。一個新的版本的 view 應該依然可以與之前已存在的 view-model 一起運行。

如果已經存在一個封裝好了已有業務邏輯的 model ，改這個 model 可能會比較困難或有風險。在這個場景中，view-model 應該作為一個 model 類的適配器，從而避免 model 的代碼需要做大的變動。(譯者注：也就是說，view-model 應該對 model 中的數據做一些基礎轉換，從而去適配新的 view 或交互邏輯)

更多關于 MVVM 的信息，參考以下文檔： Implementing the MVVM Pattern.aspx) Advanced MVVM Scenarios.aspx)

MVVM 作為2005年微軟提出來的 UI 架構，我認為在經過這么多年的檢驗之后，還是非常值得信賴的。雖然在這一兩年隨著 React 的興起，以及在前端領域“起死回生”的函數式編程，MVVM 被各種錯誤或‘惡意’的解讀導致其花式被黑。但是在我看來，MVVM 作為一個完整的 GUI 架構，跟 Flux 流派的數據層架構本身理念上是并不沖突的。我們依然可以 M/VM 層實踐 Flux。

我認為就前端領域而言，MVVM 最大的意義在于，如果我們能很干凈的分離出應用的 view 和 M/VM，我們就可以使得整個應用的業務模型能獨立于框架運行。相比于現在換一個框架就重寫一次應用的做法(老實說我受夠了而且覺得沒什么價值)，再結合當前前端‘欣欣向榮’的狀態，如果能做到只需要花費很小的代價，我們就能快速的享受到新技術帶來的紅利，那基本上就非常美好了。