【51CTO精選譯文】在本系列文章中，我們將通過一個簡單的Silverlight 3.0實例向您展示如何通過使用當前成熟的應用程序設計模式，即“模型—視圖—視圖模型” 模式，來實現用戶界面層與其相關數據層的分離設計。本文原文講述內容針對Silverlight 2.0，不過據譯者觀察，Silverlight 2和Silverlight 3在架構方面沒有太大變化，此文內容可以通用。

一、引言

當前，Silverlight的正式版本為3.0，基于此技術的應用程序數量正在急劇增長。但是，到目前為止，Silverlight 3.0模板所支持的基本結構卻意味著用戶界面（UI）與其所需要的任何數據間是緊密集成的關系。雖然這種緊密集成的技術對于學習Silverlight本身來說是有益的，但是，當使用之來開發真實的應用程序時卻會為測試、重構和維護等工作帶來巨大的困難。

二、緊耦合設計帶來的問題

在設計Silverlight應用程序時，我們所關心的核心問題是緊密耦合問題。造成這種緊密耦合的原因是：開發過程中，我們很容易把應用程序的各個層混合在一起。當一個層中擁有另一個層中所需要的大量信息時，說明你的應用程序正處于緊密耦合狀態。我們不妨來考慮一個簡單的Silverlight數據輸入應用程序，假定此程序允許你查詢某個城市的待售房屋信息。在一個緊密耦合的應用程序中，您可能會在用戶界面中的一個按鈕的Click事件處理程序中定義執行搜索的查詢操作。于是，當規則改變或搜索語義發生變化時，無論是數據層還是用戶界面層都必須進行相應的更新。

這種情況勢必導致代碼質量和編碼復雜性的問題。每當數據層改變時，你必須進行同步更新并測試應用程序，以便確保所做的更改沒有與發生的變化相違背。當一切都緊密地綁在一起時，在一個應用程序某一部分中的任何變化都可能會導致在代碼的其他部位發生相應的變化。當你使用Silverlight開發簡單的程序，例如一個電影播放器或菜單組件，緊密耦合的應用程序組件不太可能造成大的問題。但是，隨著項目尺寸的不斷增大，你會感覺到麻煩越來越多。

另一個問題是單元測試的問題。當一個應用程序是緊密耦合型的，你只能進行應用程序的功能（或用戶界面）測試。同樣，這對于一個小項目不是什么問題，但是隨著項目規模和復雜性的不斷增長，能夠分層測試應用就變得非常重要。請記住，單元測試并不只是確保當在一個系統中使用它時此單元能夠工作，而是需要確保它能夠在一個系統中繼續不斷地使用。對系統各個局部進行單元測試可以保證，隨著系統的變化，在這個過程中會更早期地發現問題，而不是和僅使用功能測試那樣在最后才發現問題。因此，回歸測試（例如，針對一個系統的每一個版本都進行單元測試）就變得至關重要—它可以確保系統中新增加的小變化不至于造成一系列的錯誤。

在程序開發過程中，定義不同的層可能會對一些程序員造成巨大的壓力。但是，事實是：無論你是否考慮到基于分層思想構建程序，你都是工作在一個N層平臺上，而且你的應用程序也都將分層工作。因此，如果設計之初缺乏正確的計劃，你的應用程序最終將要么成為一個緊耦合的系統，要么充滿了大量的硬編碼，從而為以后的應用程序維護帶來巨大的難題。

人們很容易以為建立一個有獨立的層次的應用程序一定需要大量的基礎設施才能使其良好地工作。但事實上，實現層之間的簡單分離卻是相當直接的事情。當然，你還可以通過使用控制反轉等技術設計更復雜的應用程序分層，但這是要解決另外一些不同的問題—在本文中并不予以討論。

三、以分層模式設計Silverlight應用程序

Silverlight程序并不要求你發明什么新東西，以便幫助你決定如何實現一個應用程序的分層設計。事實上，已經有一些眾所周知的模式可以供你使用。人們很快會想到的一種模式是MVC（模型－視圖－控制器）模式。在MVC模式中，模型是數據，視圖是用戶接口，控制器是位于視圖、模型和用戶輸入之間的編程接口。但是，這種模式在類似WPF或Silverlight應用程序中實現聲明式用戶接口編程時效率并不高，因為這些技術所使用的XAML可能會在輸入與視圖之間定義某種接口（因為數據綁定、觸發器和狀態都可以以聲明方式存在于XAML代碼中）。

MVP（模型—視圖—提供器）是另一個實現應用程序分層設計時常見的模式。在MVP設計模式中，提供器負責制定和管理視圖的狀態。像MVC模式一樣，MVP模式也不太適合目前的Silverlight模型，因為XAML代碼中可能包含聲明式的數據綁定，觸發器和狀態管理。那么，這種模式帶來我們怎樣的啟示呢？

另一方面，值得慶幸的是，WPF社團已經推出一種稱為MVVM（模型－視圖－視圖模型）的模式。這種模式是對MVC與MVP模式的改進。在該模式中，視圖模型部分為視圖部分提供了一個數據模型和行為，但允許視圖部分以聲明方式綁定到視圖模型上。于是，視圖部分變成了一種XAML和C＃的混合體（就像Silverlight控件一樣），而模型部分描述了提供給應用程序的數據部分，由視圖模型準備模型部分，以便把它綁定到視圖部分。

在MVVM模式中，模型部分特別重要，因為它封裝了對底層數據的訪問—無論訪問方式是通過一組Web服務，一個ADO.NET數據服務，或是一些其他形式的數據檢索方案。該模型部分與視圖模式是相分離的，從而使視圖的數據（即視圖模型部分）能夠獨立于實際數據進行測試。圖1展示了一個MVVM模式的例子。

 
圖1. Model-View-ViewModel模式示意圖

四、構建示例方案

#T#在簡單地總結了流行的應用開發模式之后，為了幫助您更具體地理解MVVM模式的實現方案，我們來分析一個簡單的Silverlight 3應用示例。當然，這個例子未必反映了實際的情形，僅用于說明這一模式。

這個例子由五個不同的項目組成，共同存在于一個Visual Studio解決方案中。（盡管你不需要針對每一個單獨的項目創建一個單獨的層，但是這樣做卻往往是一個不錯的選擇。）請注意，這個例子把整個解決方案進一步分離到兩個文件夾中，即Client文件夾和Server文件夾。

其中，在Server文件夾中有兩個項目：一個ASP.NET Web應用程序（MVVMExample），它將負責承載我們的Silverlight項目和有關服務；另一個是一個.NET類庫項目，它包含了數據模型部分。

在Client文件夾中有三個項目：一個Silverlight項目(MVVM.Client)，用于實現我們的應用程序的主用戶界面；一個Silverlight客戶端庫(MVVM.Client.Data)，其中包含了模型部分和視圖模型部分，還有服務引用；最后一個是Silverlight項目(MVVM.Client.Tests)，其中包含了單元測試內容。從圖2中你可以觀察到這種拆開來的項目布局。

 
圖2. 示例程序項目布局圖

在本例中，在服務器端構建上，我使用的技術有：ASP.NET，Entity Framework（實體框架）和一個ADO.NET數據服務。從本質上看，我在服務器端創建了一個簡單的數據模型，而且選擇基于REST的服務方式來對外提供這種數據模型的使用。篇幅所限，有關ADO.NET數據服務的細節討論，在此略過。

五、小結

在本篇中，我們首先介紹了在設計Silverlight應用程序時最令我們所關心的緊密耦合問題。然后，介紹了幾種流行的軟件開發模式，并最終確定MVVM模式最適合于目前的Silverlight 3應用程序開發。最后，簡單給出了我們要開發的案例的大致架構布局。

原文：Model-View-ViewModel In Silverlight 2 Apps 作者：Shawn Wildermuth