我，第一次用到外觀模式，應該是3年多以前。那時候是做一個收費系統，在當時的U層和B層之間，加了一層Facade。當時，在一些複雜的業務邏輯處理時，感受到了加入外觀層的好處，但對於一些簡單的（我指的是，當時很多facade裡面的方法都只是簡單的返回了B層的方法執行結果）業務，總感覺是沒有必要了。那麼，外觀模式，究竟可以發揮出多大的威力呢？？？？

一、目前的框架

後來，在專案的開發中，用到的設計模式不算少。但外觀的比例，卻也真的沒有那麼大。那麼最近呢，公司的框架，在service之上，再增加了一個facade層，將facade的介面服務註冊到Dubbo中心，對外統一提供API服務。整個的設計師沒有問題的，但是，對於架構組的說法，以及目前的用法，我談一下我的思考（我認為自己對，但我不太確定，只是簡單說一下我的看法）

首先，我先整體的說說專案中框架裡的呼叫關係（哈哈，猜的沒錯，本寶寶要手繪圖紙了。醜啊）

我先大概介紹一下。

1，關於事務，採取的是宣告式事務，加到了service層，粒度是整個類！首先是我感覺整個類上都加上註釋，統一為一樣的預設配置，這種做法是有待考究的。因為我不認為每一個方法需要的事務行為都是一致的，再極端一點，我認為有些單表的單條資料操作，不需要事務！ 而，我自己的想法是，因為我們統一對外的介面是facade層，所以，我認為是將事務控制到facade這層的方法。 而不再需要在service層加類事務註解，甚至是在基類baseservice上也加上事務管理。      但，當時跟我說的是，由於我們的facade介面對外實現，是通過Dubbo進行的，所以如果將事務註解到facade，可能會和Dubbo之間發生一些別的問題！（這一點，我還沒有仔細研究過Dubbo的機制原理和協議，不太肯定

2，對於外觀模式的作用。

引用自《大話設計模式》：外觀模式（Facade）：為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

外觀模式的使用場景，三個階段：首先，在設計初期階段，應該要有意識的將不同的兩個層分離；其次，在開發階段，子系統往往因為不斷的重構煙花而變得越來越複雜，增加外觀facade可以提供一個簡單的介面，減少他們之間的依賴；第三，在維護一個遺留的大型系統時，可能這個系統已經非常難以維護和擴充套件，為新系統開發一個外觀類，來提供設計粗糙或高度複雜的遺留程式碼的比較清晰簡單的介面，讓新系統與facade物件互動，facade與遺留程式碼互動所有複雜的工作。

而我們的這個系統，從嚴格意義上來說，也算是一個需要與舊系統實現打交道的，業務都比較成熟。在換新框架的時候，業務邏輯複用，但程式碼上的複用不多甚至沒有。所以，從某種程度上來說，也算是一個新的系統。 簡單類比到外觀的使用場景，那麼應該符合第二點。

先再看看外觀的用途：

所以，我就認為當前的facade層只是簡單的返回service的方法，那麼增加這一層的意義不大。因為增加facade這一層，它並沒有做到簡化解耦當前專案中controller呼叫Dubbo服務介面的依賴，因為介面基本等同於service層！   （個人目前的拙見）

而且，外觀模式，是一種結構型的設計模式。什麼是結構型？？？？

二、API Gateway

談到外觀模式，就聯想到最近正在做，正在計劃引入專案的API閘道器服務。在這裡面，我就感受到了外觀的精巧奇妙。嘿嘿（來張漂亮的圖）：

API 閘道器，事實上就相當於外觀，客戶端統一從API閘道器服務中呼叫服務，而API Gateway負責整合具體的服務。

看看API閘道器的優點（我認為很多就像是外觀模式的優點）

1，使服務和客戶端解耦。

2，使客戶端和服務部署環境解耦。

3，提供了最佳的API給每個客戶端。

4，減少的請求/往返次數。例如，API閘道器可以一次性檢索多個服務的資料。更少的請求也意味著更少的開銷，提高了使用者體驗。一個API閘道器對於移動應用至關重要。

5，簡化了客戶端的呼叫，因為API閘道器可以組合服務，並提供組合後的façade介面。

對於API Gateway這一段的說法，更詳細的可以參考：

三、總結

這次的總結，其實就兩句話：

1，如無必要，勿增實體

2，已增實體，就必須發揮其最大功用（而且是好的用處）

第三點，算是對於自己的一個反思：我需要好好深入的學習一些東西，要做到從理論和實踐都能具有強大的說服力。而且，在研究這段的過程中，發現自己對於理論的聯絡能力和辯駁能力都增強了很多，但是實踐的速度太慢。比如，測試事務加到哪兒的那一塊內容，測了好幾個小時，才測完了加到不同地方，不同執行操作的影響。

我還可以做到更好，加油！  嘿嘿，整整API getaway ，特別好玩兒的一個東西！