在討論什麼是Facade Pattern之前，我們先來看看一個在實務上我們經常會用到的技巧。
在常見的三層式架構中(3-tier)中，最底層通常會是Data Access Layer，這個Layer主要將與實體資料儲存裝置之間的溝通時需要用到的繁瑣步驟封裝起來，以方便Business Logic Layer在與資料儲存裝置溝通時能夠有一個簡單以及穩固的開放介面。
在上面的範例中我們可以看到，當客戶端希望執行資料庫查詢時，只要將組成的指令傳送給ExecuteCommand這個函式，其餘內部的Connection與Command物件的建立與實際的執行就交由DataAccessObject去代為處理，簡化了客戶端原本需要自行撰寫的程序。
這種將做法有許多好處。
首先，我們都了解資料儲存裝置與系統平台發生變異的機率非常高，將未來容易發生變異的部分抽離系統核心的商業邏輯，並且以穩固的介面與商業邏輯之間鬆綁，可以避免日後資料儲存裝置或者平台發生變動時，對系統本身的影響能夠降到最低。
其次，淬取出來的商業邏輯的再利用性也因此提高了，我們可以將之使用在其他類似的專案或者其他平台的版本上。而被分離出來的Data Access Layer也可以重複利用在其他專案上。
最後，這樣的架構下，也有利於我們做團隊分工的工作分派。
回到本篇文章的主題，Facade Pattern，這個架構跟Facade有什麼關聯呢？其實，這樣設計Data Access Layer的方式就是一種Facade Pattern的實作。
Facade的目的就是將複雜的介面簡化，將複雜與瑣碎的步驟封裝起來，對外開放簡單的介面，讓客戶端能夠藉由呼叫簡單的介面而完成原本複雜的程式演算。
看到這裡我們可以知道，其實Facade的概念可能早就深植在你心中，祇是你自己不知道而已。在了解Facade的觀念之後，我們可以更進一步將Facade發揚光大。
但是還是要提醒一件事情，任何Pattern都是有他的目的存在的，而且也不見得處處使用貫徹就一定是件好事，我們也要了解，當架構層次越是複雜，通常也代表會犧牲一部份的效能。
究竟要如何使用，端看設計師的經驗與現實考量了。
2008/6/26 21:00|
閱讀數 : 458
|
我要推薦
|
|
文章分類:
理論基礎
訂閱