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

一、引言

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

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

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

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

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

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

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

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

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

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

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

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

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

四、構(gòu)建示例方案

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

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

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

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

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

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

五、小結(jié)

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

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