系統架構師-基礎到企業應用架構-表現層

作者: CallHot 來源: 博客園發布時間: 2010-10-21 17:42 閱讀: 1227 次推薦: 2 原文鏈接 [收藏]

一、前言

最近也許是由于假期的原因，我發布的文章的速度變慢了，對大家說下抱歉，這個系列的確我很難寫，感謝大家對我的支持和關注，的確我在發布后得到大家的支

持和認可，讓我有了更多的動力，之前發布的有些內容，可能對各層講解的內容的廣度還不夠，當然這和我個人的水平面有關，還請各位多多提出寶貴意見和建議。

從本篇開始，我將會采用更加規范的格式，更嚴謹的求知態度，更加準確的表達，去將接下來的系列文章寫完，并且與群中的很多朋友交流后，他們希望出一個總

的PDF電子書，這樣可以方便閱讀，的確謝謝各位的支持，我目前將以后每篇寫的內容，放一份PDF格式的在群共享中，有需要的朋友可以進行相應的下載，由于本人

的寫作水平有限，所以在書寫的深度和書寫的格式上還有很多的缺點，還希望大家多多指出。

二、開篇

本篇我們將針對系統架構分層中的表現層進行講述，分析表現層的架構與設計模式，當然我們會結合目前比較流行的表現層模式進行分析講解，主要是圍繞MVC模

式的起源及發展的過程進行講述，并且分析目前MVC模式在不同UI層中的應用設計，由于本人的水平有限，加之實際的項目中可能應用的理解和經驗水平不足，可能在

某些分析的地方不對，還請大家提出。我們之前的寫作慣例，我們先來看看本文的主要講述的內容吧

本文將會以上面的2點為主線展開去講解表現層的內容。

三、內容提要

1、前言

2、內容提要

3、本文提綱

4、表現層模式

4.1、表現層的職責

4.2、UI層與表現層邏輯

4.2.1、用戶界面的職責

4.2.2、表現層中容易產生的誤區

4.3、MVC模式的提出及演化

4.3.1、MVC模式

4.3.2、MVP模式

4.3.3、MVC模式與MVP模式的對比和總結

5、結束語

6、系列進度

7、下篇預告

四、表現層模式

4.1、表現層的職責

我們知道任何一個應用程序，如果想要更好的與客戶交互，我們一般都是通過提供一個用戶界面去完成與用戶的交互，當然通過前面我們講述的，服務層與業務邏

輯層的講解，其實都是為了更好的為表現層服務的，通常，我們都不是特別的重視表現層，但是其實，表現層同樣重要。其實通常我們在關注各個分層的時候，我們對

每個分層的重視程度會不同，可能是由于我們自身的愛好，態度，或者是專業技能所決定的，但是一個好的系統，必然要求我們不管哪個分層都要足夠的重視。

我們在做表現層時，通常我們會關注下面幾個組件，首先是用戶界面。也就是客戶能夠看到的用戶界面簡稱UI，還有一部分就是與用戶行為進行交互的組件，通常

我們叫做表現層邏輯，用戶的所有操作都通過表現層邏輯來支持，表現邏輯層將負責其他層與UI層之間的交互。

根據我們前面講述的各分層的設計我們知道，表現層邏輯將主要與服務層或者業務邏輯層進行交互。具體的關系如下：

通過上圖我們知道表現邏輯層的位置，可以說如何組織好用戶界面及表現層邏輯同其他層之間的關系，就是決定設計好壞的關鍵。也可以說表現層邏輯決定了用戶

與系統交互。

下面我們來先看看表現層的職責吧

我們一般都把如下職責看作是表現層的職責，是不是你也有相同的看法？

其實，像圖中說的驗證，格式化，添加樣式等這些更應該屬于UI層組件，而不應該屬于表現層，但

是作為架構師，你必須考慮的更全面，從更高的層次去考慮，比如說下面的幾個方面：

只有更好的考慮這些因素，才能決定表現層的架構，我們針對上面的幾個方面來

簡單的分析一下。

1、UI的無關性：

這里的UI的無關性就是指不依賴UI層的實現技術，不管是上面說的Web還是Winform，還是其他的WPF、WP還是其他的任何UI表現形式。我們知道這樣的表現

層設計出來是理想的，我們只是想盡可能的提高可復用性，我們希望的是雖然不同的UI使用的實現技術不同，但是這些UI能夠共用表現層邏輯，這時候我們就能做到很

好的復用性。

我們需要知道，這里提出的代碼重用只是說是盡可能大的做到表現層邏輯重用，但是有些情況我們沒有辦法做到，例如Silverlight與WPF，由于他們使用不同的

CLR，所以我們只能說是做到代碼重用，我們需要針對他們各自進行單獨的編譯。

2、可測試性

任何分層都需要能夠測試，因為只有測試才能知道功能是否能夠很好的滿足需求。但是通常來說表現層的測試，相比其他分層要復雜一些，因為表現層需要考慮的

因素很多，所以決定了測試的難度，所以更好的測試性就是我們架構設計的基本要求。

一般來說我們在表現層的處理流程是這樣的：

上面的圖中大概描述了，我們在表現層中的基本流程，我們來結合圖形來說明下：用戶界面通過用戶

操作，將觸發相應的行為事件，這些事件將會被某個特殊的控制器進行處理，控制器通過發送給指定的處理函數，然后將處理函數返回的結果，反饋給用戶界面。

通過上面的流程我們知道，我們測試時必須模擬用戶的行為，并且如何保證用戶的行為事件能夠得到正確的處理，這些都是我們必須測試的內容。我們如果將所有

的內容都寫在表現層，那么我想可能測試起來不會那么容易，如果說我們的用戶界面與表現層邏輯寫在一個頁面中，可能我們并不容易測試，幸好APS.NET中通過代碼

后置的技術，實現設計層與表現層邏輯代碼的分離。當然我們在之前就對架構設計的實現提出了一個觀點，就是分離功能點，將關注的功能點進行分離，提出更高的抽

象，這樣可以達到更好的測試的目的。

3、不依賴數據模型

在服務層、業務邏輯層中我們都提到了數據傳輸對象，并且把這個對象作為與表現層通信的載體，使用了數據傳輸對象后，那么我們就可以做到表現層不依賴于我

們的數據模型，但是我們也講過，數據傳輸對象為項目帶來了更多的類，更多的工程文件，所以這會對我們的開發工作帶來額外的工作量。因為不同的表現層需要一個

與之對應的數據傳輸對象，這些都和前面我們介紹的情況是一致的。因此，我們在項目中是否使用數據傳輸對象，我們需要根據項目的需要來決定。

4、不依賴圖形化元素

我們這里的圖形化元素是指，開發工具給我們提供的控件和工具集合，我們通過這些圖形化元素設計出與用戶交互的界面，我們希望我們的表現層能夠在不同的控

件上可以以不同的方式表現出來，我們同時希望圖形化元素中的任意修改不會影響到表現層邏輯，舉個例子，我們平時在博客園中的模板設計，其實就是個很好的例

子，我們選擇不同的模板，我們的博客頁面就會在皮膚，樣式，主題等方面都發生變化，但是并不影響我們的表現層。

4.2、UI層與表現層邏輯

4.2.1、用戶界面的職責

我們接下來看看UI層的相關職責，我們知道，我們平時在系統設計過程中，一般架構師不會直接參與到用戶的界面的設計中，架構師更側重系統的可用性和可訪問

性。我們認為UI層的主要功能包括下面幾項：

下面我們來分別說說吧

1、數據顯示

我們都知道UI層是用戶使用系統的唯一入口，那么首先用戶界面必須將系統中的一些信息進行展示，這些信息可能包括，普通信息、提示信息、系統中的相關數據

信息等，良好的設計UI能夠很好的展示數據，用戶界面需要支持本地化及全球化功能。

2、友好的交互

交互就體現在用戶使用系統的功能，這樣就會有這樣的操作，用戶輸入相應的數據，通常來說一個好的UI層，會提供給用戶一個比較人性化的輸入頁面，并且會根

據用戶的輸入，返回用戶想得到的結果。不管UI層的具體技術是什么，好的用戶交互頁面都是系統中最重要的部分。輸入的數據我們如何做到安全性方面的驗證，是我

們必須重視的部分。

3、總體外觀

系統的功能都是通過用戶界面來作為統一入口，提供給用戶使用的，所以一般來說我們在設計UI時必須要有精致的用戶界面，軟件的目的就是抓住用戶，能夠給用

戶較好的用戶體驗，而且根據軟件的用戶群來進行不同的設計，如果是提供給大眾使用的軟件，那么我們必須達到設計精致的用戶界面的要求，如果是提供給企業內部

使用，那么我們可以注重功能而不是視覺效果的震撼，當然不是說不重視UI，只是沒有那么重視。

4.2.2、表現層中容易產生的誤區

我們來看看我們平時在表現層的設計與實現過程中可能存在的誤區吧

我們來看看每個誤區的說明吧

1、過度依賴工具

自從有了Visual Studio 開發工具以來，就因為其提供了大量的控件，為我們開發簡單的應用程序提供了很大的方便，我們通常都是通過拖拽控件來完成UI層的設

計。我們通過一些帶有事件的控件，去完成與其他層之間的交互，我們可以在事件中直接處理邏輯，而且很方便很快捷。這也使得我們的開發效率很高，當然這是開發

簡單的應用程序時我們通過這樣來做，沒有什么問題。但是，當我們開發大型的企業級應用時，這樣的方式可能就不是理想的選擇了，為什么這么說呢？我們不是說不

用開發工具提供的控件，而是應該將職責進行劃分，比如說，用設計器完成界面的設計，然后其他的代碼都是通過我們的手工邊寫，而不是通過開發工具提供的一些控

件去完成，比如說Visio Studio 提供的數據源綁定控件等，而且如何將事件中的代碼進行更好的抽象就是我們這里的需要考慮的問題。

2、表現層的邊界

我們先要清楚表現層的職責是什么？它主要負責什么？我們知道，表現層中的UI層是個很薄弱的層，UI層應該只負責與用戶進行交互，表現層邏輯應該負責協調數

據流入/流出UI層，那么這里的表現邏輯層應該具有什么樣的功能。我們在前面介紹業務邏輯層中也提到過，我們有時候將業務邏輯放在表現層中也是可以接收的，還是

看具體的系統需要。

有的時候我們很鐘愛把業務邏輯層中的功能反正表現層邏輯中，我自己的很多項目中也是這樣做的，因為我目前的項目中也有這樣的代碼充斥者，我們說過這不是

萬惡的，但是當系統有一定規模時，表現邏輯層就會變成一個無所不有，無所不包的容器，難以維護和測試。

通過上面的分析我們知道，我們還是需要根據系統的實際需要來決定是不是把一些業務邏輯寫在表現邏輯層中，對于大型的企業級項目來說，我們必須考慮這些問

題，因為好的設計可以提供測試行，維護性等，我們對表現邏輯層的要求也會比較高，我們期望通過SOC來實現，我們一般是通過分層來實現，因為分層來分離功能

點，我們通過分離關注點可以提供表現邏輯層的重構，提醒更好的設計結構和代碼結構，提高復用性。

3、WUGWYW

大家估計出一看，還以為是什么意思呢，原諒我這里賣了個關子，意思就是說(what–user-get-is-what-you-want)用戶得到的就是你想要的。

我們在使用圖形化的界面設計工具時，為了能更好的提供開發效率，現在很多的開發工具提供了界面預覽的功能，基本上是所見即所得，但是并不是全部，例如

Visio Studio 提供的web開發中的預覽，但是有時候我們還需要自己動手去處理一些表現層的東西，所以我們會對界面通過CSS去控制UI層的顯示，我這里解釋這個的

意思就是，有時候我們需要多寫一些代碼來提供更好的功能，滿足用戶的需求。

4.3、MVC模式的提出及演化

從本節開始我們就開始對表現層中的模式進行講解，我們主要是針對MVC模式的起源及發展過程進行講解。

4.2.2、MVC模式(Model-View-Controller)

MVC模式起源于上個世紀80年代，目前已經有了30年的歷史了，在現在的今天，可能我們沒有辦法再使用原來的定義去完成表現層的設計了，但是我們現在使用

的MVC模式都是從原來的MVC模式中演變過來的，以適應目前的軟件開發需求。我們這里可能說的MVC模式也不是原始的定義，包括后面介紹的MVP模式等。

我們這里需要知道表現層都有哪些分類，每種分類可能演變出哪些哪些分類等，這對我們對表現層的模式有個大概的結構，對我們對表現層的設計有很大的幫助，

下面我們來看看吧:

我們將會詳細的講解這些模式及應用，本節將詳細的講解MVC的演變及原

理，其中由MVC模式演變的Model2模式正式目前ASP.NET MVC的實現方式。

在早起我們開發表現層的時候，我想我們更多的是將表現層邏輯與視圖放在一個文件中，可以看作是功能自治的視圖。用戶與視圖交互，視圖負責捕獲用戶的輸入

信息，并在內部處理，然后更新自己或者跳轉到另外一個視圖。這樣的組織形式，不但難以維護，更難測試，因此更加讓大家渴望有一種好的模式，從這樣復雜的表現

層中分離出來，由此MVC模式便提出來了。

MVC模式的提出，將我們從視圖自治的設計方式脫離出來，自治的視圖內部的處理，可能包含業務層，數據訪問層或者服務層等等，當然還有自身的設計層。MVC

模式，則讓我們把自治視圖的功能進行分離，將自治視圖分解成，視圖層，控制層，模型的形式，來分離關注點，通過關注點的分離，來降低系統的復雜度，進而提供

系統的更好的設計性。

那么MVC模式，也有人稱作模范，那么MVC到底是模式還是模范呢？我們來看看模式與模范的定義吧？可能就更能理解MVC了

模式在軟件領域中是指一個被證明過的，具體的某類問題的解決方案。

模范是指某一類相似問題的解決方案，一般是指一類相似的模式。

通過上面的解釋，我們知道MVC是模式。

我們來看看自治視圖與MVC的結構上的區別，MVC模式我們知道將自治視圖中的功能進行分離，分離成功能相對獨立的組件，并且通過這些組件的交互完成表現層

的工作。

可以這樣說，自治視圖將所有的功能放在一個容器中，而MVC模式關注的是功能點的分

離，通過功能的分離開實現，我們通過將表現層劃分成3個不同角色的組件，通過這些組件之間的配合來完成自治視圖完成的工作。

MVC的原始定義是什么呢？我們來看看，通過書上的記載稱，MVC的原始定義中，將模型作為業務邏輯的入口，模型中，我們能夠看到程序的狀態，我們需要將模

型中的數據顯示在視圖中并且視圖中接收用戶的動作，然后通過模型來響應用戶的操作行為。模型會處理控制器中發出的操作請求，一般來說這些請求都會對模型的狀

態有一定改變。

但是目前隨著表現層模式的發展，現在MVC的定義已經不像原始定義的那樣了，現在的模型只負責保持應用程序的狀態，大多數的工作都是在視圖和控制器來完

成，控制器成為更核心的組件。我們現有的MVC模式中對模型的定義可能更多的采用是業務中的數據對象，或者專門針對領域模型來構建的領域對象或者是數據傳輸對

象。當然還是根據我們在工作中的項目的需要來決定了。我們來看看MVC模式中的簡單的這幾個組件之間的調用關系吧

當然大家請不要詫異，這是最原始的MVC模式的處理流程。當今比較流行的MVC框架中流程已經不是這樣處理的了，但是我們通過了解原始的定義將對我們更深入

的了解MVC有所幫助。MVC當時的提出，并不是針對WEB來說的，但是MVC模式的發展，卻是在WEB上流行起來的，像現在微軟提供的ASP.NET MVC框架對MVC進

行很多的優化和修改。我們后面會講述這個模式的原理。

我們來詳細的看看MVC中的視圖可能的代碼：一般來說視圖層通過一些界面設計的控件元素向用戶展示相關的信息，用戶通過界面層完成與系統的交互，那么我們

如何在視圖中捕獲用戶的操作呢？視圖通過一些列的控件去完成用戶動作的捕獲，比如說輸入框，或者按鈕等，視圖的前臺通過委托與后臺的代碼綁定，我們知道，微

軟在處理.NET的表現層中有很大的技巧在其中，通過視圖與后臺代碼放在不同的類文件中去完成分離，這樣，視圖中用戶發出的動作將會在代碼后置類中捕獲，然后進

行相應的處理。

我們先來看看控制器的可能代碼

   /// <summary> 
   /// 控制器類 
   /// </summary> 
   public class Controller 
   { 
       public void Action(ActionType actionType) 
       { 

       } 
   } 

   /// <summary> 
   /// 控制器完成的動作 
   /// </summary> 
   public enum ActionType 
   { 
       Add, 
       Delete, 
       Query, 
       Update 
   }

視圖中的可能代碼：

        private void button1_Click(object sender, RoutedEventArgs e) 
        { 
            Controller controller = new Controller(); 
            controller.Action(ActionType.Add); 
        }

代碼中的控制器可以是任何特定技術的視圖，控制器將會為視圖中每個可能發生的操作，提供一個專門的方法，每個支持用戶操作的動作都對應著一個與之相關的

處理服務。視圖負責數據的呈現，控制器負責更新模型，如果模型發生變化，那么將會通過觀察者模式通知視圖其狀態發生變化，然后視圖將會決定是否將模型的變化

體現在視圖上，如果需要更新，那么視圖將會從模型中讀取最新的數據信息。

MVC中的模型我們上面羅列了幾種可能，如果說我們這里的模型是業務邏輯層的話，那么我們就會直接調用業務邏輯對象中的方法完成模型狀態的更新，這些都是

控制器來完成的，如果說MVC中的模型是數據傳輸對象，那么可能控制器將會通過業務邏輯層抽象出來的服務層的接口來訪問與該數據傳輸對象相對應的公開方法去完

成模型的操作。如果說我們這里的模型是業務模型，那么控制器只是完成路由的功能，先要解析動作的發出者，然后要將這個動作解析交給哪個業務模型來處理，轉發

完畢后就忘記了，其他的就有業務模型自動完成。

控制器有時候還要負責選擇呈現視圖的跳轉功能，如果需要跳轉時，那么控制器就會創建新的視圖，控制器，模型。

我們有時候可能想要通過全局配置的方式去完成重定向，比如說通過XML文件去配置，類似工作流那樣的方式來做的話。通過配置定向頁面，那么我們如何來做

呢？我們就需要提供一個服務層完成定向，比如說通過一個通用的類去完成這樣的操作。

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
  <route> 
    <urls> 
      <url key="key" value="value.aspx"> 
      </url> 
    </urls> 
  </route> 
</configuration>

具體的路由代碼如下：

    public class Route 
    { 
         public Route() 
         { 

         } 

         /// <summary> 
         /// 重定向服務 
         /// </summary> 
         public void RedirectUrl(string key) 
         { 
             string url = XMLHelper.GetValue(key); 
         } 
    }

當然我這里只是給個可能的思路去完成服務地址的跳轉，并不是比較好的方案。

通過上面的講解我們知道，視圖的更新并沒有提出由誰來操作完成。通常來說有2中模式，我們來看看吧

后面我們會講s解ASP.NET MVC模式中的視圖更新的模式。

我們接下來看看MVC在WEB端開發的變體吧，那就是Model2模式，我們先來看看這種模式相比之前的MVC模式都有哪些變化吧

主要差別體現在以下幾個方面，在MVC模式中，視圖和模型有一定的關系，模型發生變化將會通過觀察者模式通知視圖，視圖的更新，我們是通過視圖主動請

求模型來完成更新的，而在Model2中，視圖和模型是獨立的，視圖的更新是通過控制器來完成的，控制器根據模型的變化來通知視圖的呈現及數據的變化，還有就是該

模式中，用戶的操作不是通過視圖來捕獲的，是通過一個web組件，前端控制器來完成的，前端控制器負責攔截HTTP請求，然后根據這個請求的URL和HTTP頭信息，

去決定使用哪個控制器去處理該請求。

基本上這個流程是Model2的處理流程。這個流

程也是APS.NET MVC框架背后用到的模式，相信大家對背后內容的理解，將更容易讓我們在使用框架的過程中加深理解。

Model2模式相比MVC模式都有什么樣的優點呢?

可以肯定的是，Model2具有更好的適應性，更好的可測試性，可維護性，并且相比原始的MVC模式，Model2的效率更高。這個怎么說呢？

原始的MVC模式流程：我們的頁面請求流程是這樣的，用戶的每個操作將會產生一個HTTP請求，然后服務器根據請求地址，將映射一個處理頁面，然后該頁面開

始一個生命周期，完成用戶操作的請求。

Model2模式的流程：通過上面的圖形我們知道，用戶的操作同樣是通過HTTP請求，被前端控制器捕獲，然后控制器將控制權交給具體的控制器去完成處理，而不

需要交給指定的頁面去完成處理，這樣還需要給頁面創建一個生命周期，同時這種方式能夠讓視圖做到非常的被動，而不是主動更新，我們將關注點轉移到控制器中，

而不是視圖上，測試時更容易測試。

我們需要注意的是Model2中的模型不是業務模型，也不是領域模型，這個模型是專門與視圖進行交互的對象，我們叫做ViewModel，MVC框架中會為我們提供一

個與ViewModel對應的容器。容器負責創建各類的ViewModel對象。MVC的流行也是因為它發揮了系統架構的原則：分離功能點的重要性，所以才會讓它如此流行。

但是MVC還不完美，我們下面來看看改進MVC不足的另外一類模式MVP。

4.3.2、MVP模式

我們閑來看看MVP模式的解釋，MVP是將MVC模式中的控制器換成展示器,MVP模式巧妙的將模型從視圖/控制器中分離開來，我們將其叫做展示器，我們需要知道MVP模式是從MVC模式的基礎上衍生出來，在MVP模式中，我們通常是這樣去完成交互，展示器通過接口訪問視圖，這樣做的目的是，展示器將不關心視圖的實現形

式，只要實現接口，那么就能通過展示器來完成相應服務。當然如果我們再考慮展示器與模型之前的調用，如果也通過接口來完成，那么我們就將關注的中心放在展示

器上了，這樣更容易測試，視圖及模型都可以通過模擬來實現。這樣將大大的提高可測試性。下面我們來看看MVC模式與MVP模式的差別，我們還是通過看圖說話的形

式，這樣更直觀。

MVP模式：