通過前面兩篇，我想各位朋友對“面向介面程式設計”的思想有了一定認識，並通過第二篇的例子，獲得了一定的直觀印象。但是，第二篇中的例子旨在展示面向介面程式設計的實現方法，比較簡單，不能體現出面向介面程式設計的優勢和這種思想的內涵。那麼，這一篇作為本系列的終結篇，將通過分析幾個比較有深度的模式或架構，解析隱藏其背後的面向介面思想。這篇我將要分析的分別是MVC模式和.NET平臺的分層架構。

這篇的內容可能會比較抽象，望諒解。

1.從MVC開始

MVC簡介：

本文不打算詳細解釋MVC架構，而是把重點放在其中的面向介面思想上。所以在這裡，只對MVC做一個簡略的介紹。

MVC是一種用於表示層設計的複合設計模式。M、V、C分別表示模型（Model）、View（檢視）、Controller（控制器）。它們的職責如下：

模型：用於儲存應用中的資料及執行邏輯，是應用的實體。

檢視：負責可視部分，用於與使用者互動及呈現資料。檢視只負責顯示，不負責將使用者的操作行為解釋給模型。

控制器：負責將使用者的行為解釋給模型。根據指定的策略和使用者的操作，呼叫模型的邏輯。

關於三者的關係，我畫了一張圖，大家請看：

圖3.1 MVC模式示意

它們之間的互動有以下幾種：

1.當用戶在檢視上做任何需要呼叫模型的操作時，它的請求將被控制器 截獲。

2.控制器按照自身指定的策略，將使用者行為翻譯成模型操作，呼叫模型相應邏輯實現。

3.控制器可能會在接到檢視操作時，指定檢視做某些改變。

4.當模型的狀態發生改變時，將通過某種方式通知檢視。

5.檢視可以從模型獲取狀態，從而改變自己的顯示。

 MVC介紹完了，那麼可能會有人問，我們的主題呢？面向介面思想呢？其實，MVC中處處都存在面向介面的影子。下面，我對其中幾個側面進行解釋。

1.首先我們可以看到，檢視和模型是有直接互動的，也就是上面的4、5兩點。但是有一點可能會讓你吃驚：它們兩個誰也不“認識”誰，即它們相互並不知道對方是做什麼的、有什麼屬性、有什麼方法，但是它們能互動。這是怎麼做到的呢？因為它們個各知道對方實現了某一個介面。

此乃面向介面思想一大作用：使相互不認識的類進行互動。這樣做是很有好處的，首先它們之間的耦合度大大降低，其次雙方都可以進行替換，只要實現了相同的介面，就沒有問題。

打個不太恰當的比喻。我們都知道120這個電話號碼，是急救電話。其實120就是個介面，因為當你撥打這個電話時，你不知道那邊是哪所醫院，甚至不知道那邊是不是醫院，你只知道電話那頭的地方可以救人，也可以說實現了IHelp介面。這樣，你通過一個號碼可以說同全部的救人機構聯絡起來了，當有緊急事件，接線控制那邊會將你的請求接到最近可用的機構，你就可以最快的得到幫助。

現在我們假設沒有使用面向介面思想，來看看會發生什麼恐怖的事情：首先，我家的120號碼是繫結在本市第一人民醫院的，即當我撥打120時，只能撥通第一人民醫院。如果有一天我食物中毒了，急忙撥通了120，但是電話那邊告訴我他們醫院的救護車都派出去了，我問那怎麼接通別家醫院的電話，那邊的MM很溫柔的告訴我，讓我打電話給網通公司，然後重新為我佈線。於是我吐血而亡……

言歸正傳。這裡，我要引入一個設計模式，叫觀察著（Observer）模式。這個模式大約是這樣的：整個模式中有兩種實體：觀察者和被觀察者，它們分別實現一個介面，這裡我們姑且叫做IObserver與IObserverSubject。IObserver只有一個方法，例如叫Update，當被觀察者狀態改變時，呼叫這個方法，用來通知觀察者。IObserverSubject介面有兩個方法，都是供觀察者呼叫。一個用來將觀察者註冊為此被觀察者的觀察物件，另一個用於將觀察者移除。

一般情況下，一個被觀察者對應多個觀察者。

在MVC中，檢視是觀察者，模型是被觀察者，當模型狀態改變時，呼叫所有觀察者的Update方法，通知檢視模型有變，檢視在Update方法裡寫下響應程式碼，完成操作。通過這個方法，檢視和模型就可以在僅依賴介面的情形下進行互動，而不必強耦合，而且在模型不變的情況下，檢視可以隨意替換。（只要實現了IObserver）

2. 在MVC中另一個使用介面的地方就是控制器，這裡我要首先引入一個設計模式：策略模式（Strategy）。在MVC中，控制器就使用了這個模式。

剛才我說過，檢視負責與使用者互動，但是，它只負責介面顯示部分，至於當用戶做了某個操作（如單擊某個按鈕）後系統應該怎麼反應，檢視並不負責，它只是將這個動作交給控制器，控制器根據內建的策略，將使用者操作翻譯成模型的邏輯。這就是說，同一個檢視、同一種操作，模型可以做出不同的反應，這取決與控制器的內建策略。所以，我們的系統中可以有很多控制器，它們有不同的策略，當檢視希望改變策略時，它可以更換控制器。怎麼實現呢？這就需要檢視不能和具體控制器耦合，而是要僅依賴一個控制器介面（如IController），並聚合一個IController的例項。當希望更改策略時，可以在系統執行時動態更換Controller，這就是策略模式的實現。

關於MVC的介面思想就先介紹到這裡。其實MVC中還有很多地方用到面向介面，由於本文不是專門介紹MVC或設計模式的，所以對用到的模式沒有做詳解，而是把重點放在其中的面向介面思想上。如果沒有設計模式的基礎，讀上文可能會有些困難，希望各位見諒！我打算在以後專門寫文章來解析MVC。

2..NET平臺下分層架構的面向介面思想

我們知道，在做大一點的系統應用時（特別是B/S架構），比較好的方法是分層架構。所謂分層架構，是指將系統從職責上分成若干層，每層各司其職，上層依賴下層完成操作。

在.NET平臺上，比較經典的分層架構是三層架構，從下到上依次是：資料訪問層、業務邏輯層、表示層。各層職責如下：

資料訪問層：負責與資料來源互動，完成資料訪問等一系列操作。

業務邏輯層：完成與系統業務有關的邏輯操作。

表示層：負責與使用者互動、呈現資料等一切與系統表示有關的操作。

剛才我們說過，分層架構下是向下依賴的（不考慮依賴倒置），也就是業務邏輯層要呼叫資料訪問層完成與資料來源有關的操作，而表示層呼叫業務邏輯層完成業務邏輯工作。但是，表示層對資料訪問層是沒有依賴的。

在這個架構中，每一層都不是一個類，而是一個類族，例如，在一個CMS系統中，資料訪問層可能會有一系列的類，分別負責使用者、文章、評論等業務實體的資料訪問操作，而業務邏輯層也一樣。如果我們直接依賴，即業務邏輯層例項化資料訪問層的類，表示層再例項化業務邏輯層的類，會造成強耦合。如果我想把資料庫從SQLServer換成MySQL，則要改變整個業務邏輯層程式碼，這是個不好的設計。（還記得“開放-關閉”原則嗎）所以，一般的做法是，為資料訪問層和業務邏輯層分別定義一族介面，業務邏輯層不依賴具體的資料訪問層，而是僅依賴資料訪問層的介面族，表示層也一樣，依賴業務邏輯層的介面族。如此一來，當要更換資料庫時，我們就不必改寫整個業務邏輯層，因為業務邏輯層里根本沒有任何資料訪問層中的具體類，而全是通過介面實現的。在.NET中，只要配合配置檔案和反射機制，再運用Abstract Factory設計模式，就可以實現“依賴注入”，即在不改動程式碼的情況下根據配置選擇相應的層次元件。這樣，我們就可以為不通資料庫分別實現資料訪問層，也可以編寫ORM的資料訪問層，甚至是基於XML的，只要實現了資料訪問層介面族，就可以和業務邏輯層無縫連線，從而極大提高了軟體的靈活性和可維護性。當然要更改業務邏輯層也是一樣。

如果說，前面的例子都是從微觀視角討論介面，那麼，這個例子則從巨集觀視角展現了面向介面程式設計的內涵和優勢。很抱歉在這裡不能對這個架構深入講解，有興趣的朋友可以參考微軟的官方示例.NET PetShop4。（但是請注意，這個示例中業務邏輯層沒有定義介面族，而是強耦合於表示層中，這可能是因為考慮到在這個系統中業務邏輯沒有更改的可能。另外由於是個示例，不是真正的B2C系統，所以業務邏輯層很簡單。）

好了，本系列文章就到這裡。希望各位朋友通過這三篇文章，能對“面向介面程式設計”有一定的瞭解。當然，我只是起到一個拋磚引玉的作用，其真正的內涵和精髓，還需要各位從實踐中慢慢認識。還有，就是面向介面思想不是孤立的，它和設計模式等內容都是面向物件大系中的精華，而且是相互滲透、相互聯絡的。其實，很多設計模式就是面向介面思想的體現。我們應該把這些放在一起學習，從而真正提供自己的面向物件思考能力和實戰能力。