The Framework Designing(1)

 

文/黃忠成

 

 

契

 

  在2006年，我寫了一本[Windows Forms 框架設計實務]，書中淺略的介紹了Framework，也就是框架的觀念及設計概念，時至今日，算算也過了將近5年之久了，現在的Framework與當年

我所專注的Framework雖然有一些差異，但在設計及概念基礎上還是一樣的，本文目的在於重新介紹這些概念。

 

The Framework Concepts

 

  Framework，中文上通常譯為框架，意指一系列針對[軟體設計]所需而設計並實作的程式庫，有人稱其為APIs，有人稱為Class Library，這些稱呼基本上都是正確的，具體上而言，

只要一群物件或是函式組成，並提供了彈性及延展性，那麼就可以稱之為Framework。

  Framework的設計通常不容易，其重點在於完整提供某個特定領域應用所需要的基礎設計及功能函式或物件，而且在這之上，還要提供給開發者高度的彈性及擴充性，以便能適應

軟體的變化性，這裡頭多半伴隨著多年的軟體設計經驗及架構觀，當然，Framework本身並非完美，要適應軟體的變化性並不容易，多數Framework裡頭採用一些業界常用的Design Patterns，

一方面可以讓軟體設計師快速的理解Framework的設計概念，一方面也借助這些已沿用許久，確定可以解決特定問題的Design Patterns來增強Framework的彈性及擴充性。

  但，完美的Framework事實上是不存在的，因為不同應用程式會有不同的需求及領域，沒有任何一個Framework可以涵括這一切，所以，Framework本身也被切割成多個層級，

分別為Base Framework、Application Framework及Domain-Specific Framework。

 

 

Understanding Framework Boundary

 

圖1

圖1中所繪及的是目前常見的Framework分級，其中的Base Framework指的是一群物件或是函式，例如Collections、Stack、Threading、Networking等等，單單只有這些東西並無法

讓你撰寫出網站或是Windows應用程式，但在撰寫這些應用程式時，你也缺不了它們。

真正能讓你撰寫出應用程式的，是位於Base Framework之上的Application Framework，舉例來說，當你要撰寫網站應用程式時，你可能會選用ASP.NET或是ASP.NET MVC，在撰寫

Windows應用程式時則會選擇WPF、Windows Forms、Silverlight，這些都可稱為是Application Framework。

位於最上層的，是稱為Domain-Specific Framework的東西，其架構於Application Framework之上，提供了特定領域所常用的一些函式或物件、甚至是流程，例如銀行的Domain-Specific Framework中

就可能會包含信用卡驗證、帳務追蹤的函式或物件，甚至可能提供了申請信用卡、貸款的流程控制，一個完美的Domain-Specific Framework，會讓開發人員以最快的速度，設計出同質，但流程迥異的應用程式。

 

 

Domain-Specific Framework 

 

   雖說分級上是如此，但其實也不用太執著於什麼是Base Framework、什麼又是Application Framework，因為Base Framework及Application Framework多半不是由開發應用程式的設計師所實作，而是由開發平台來提供的，

真正必須要考量的是位於最上層的Domain-Specific Framework，例如我們常用的ADO.NET、ADO.NET Entity Framework就是Domain-Specific Framework，他們提供了撰寫資料庫所需要的函式或物件，讓我們可以連結

各式各樣的資料庫，也讓資料庫廠商能基於其上推出自身的Driver或是Framework來協助設計師更快速的撰寫出應用程式，但如果不是撰寫資料庫應用程式，那麼你可能就用不到它們，這就是Domain-Specific字面上的意思。

 

 

企業用的Framework

 

   看到這裡，你應該隱約地了解到，事實上，Base Framework與Application Framework通常不是一般開發人員需要自行設計的，大多數的開發平台如.NET、Java、Power Builder都有自己的Base Framework

及Application Framework，身為應用程式設計師的我們，要執著的是Domain-Specific Framework。

　現今，許多企業都有自行開發軟體的需求，有些甚至有自己的開發團隊，這時建構出屬於該企業領域專用的Domain-Specific Framework就顯得特別重要。我們常常聽某些工程師或是業主抱怨，自己所開發的軟體，

常常三天一小改，五天一大改，每次修改都會出現Bug，最後形成不得不重新設計的窘境。但這還不是最糟的情況，最糟的情況是，根本未建構出自己的Domain-Specific Framework，導致重新設計時，

所有關鍵的流程、機制、驗證都得重新再來一遍，

美其名是流程與以往不同，事實則是當初未設計出具彈性及擴充性的Domain-Specific Framework所致。

  當然，這其中還有一種情況，那就是認為當初設計的Domain-Specific Framework需要透過一些調整才能適用於改動後的流程，所以要全部重新設計，以符合未來的變動!! 不過，醒醒吧，這不應該是拋棄整個Domain-Specific Framework的理由，

如果繞著路走不會影響太多效能或是敲毀整個Domain-Specific Framework，那麼重新來過只是給老闆讓你加班的理由(如果你想加班，那就另當別論)。

 

 

軟體廠商用的Framework

 

   與企業不同，軟體開發廠商多半要面對不同的領域，他們不可能做出一套適合各種領域的Domain-Specific Framework，但卻得接來自於各種領域的軟體專案，因此除了建構各個領域的Domain-Specific Framework之外，

軟體開發廠商有些會建造出一種Domain-Specific Application Framework，這個Framework是集Application Framework於Domain-Specific Framework於一身，簡單的說，針對雜誌業所設計的

Domain-Specific Application Framework裡，會有一整群的訂閱、贈閱、廣告、收款、付款等等的Domain-Specific Framework，彼此間以介面聯繫，當有訂閱，就可以透過收款所提供的介面將資料轉過去，

當客戶不需要帳務系統時，也可以直接抽掉收款、付款的功能，不需要重新編譯應用程式。

   組成Domain-Specific Application Framework並不難，只要謹記一個重點，多數的功能都是獨立的，且是可抽換的，要達到這點，你必須謹慎的設計各個功能的連接介面，不要以為直接就是有效率，必要時犧牲效率換來彈性，

相信我! 以開一個程式5秒跟6秒，來提高使用者體驗不會比你多賣100套軟體來得好(當然，短兵相接時，就不在此限了)。

順帶一提，Domain-Specific Application Framework再往上架構，通常就會出現Domain-Specific Application Generator。

 

 

Framework vs Architecture

 

  當你決定使用那些Frameworks來建構應用程式時，你多半也選擇了某一部分的應用程式架構，例如當你選用了Silverlight，那麼你也就選擇了使用Multi-Tier作為應用程式的

主要架構，當然! 如果你執意要寫成Single-Tier，也不是沒辦法就是了，只是這目前還是非主流的設計方式，必須冒一定的風險。

  當談論Architecture時，必須要了解，架構必須是從中貫穿的，每個人在設計應用程式架構時都有自己的經驗及考量，期間必須經過不斷的討論及調整，但切莫以效率來敲碎架構，因為，

任何具彈性及擴充性的架構，都必須要犧牲效率，

也就是說，任何具彈性及擴充性的Framework，跟高效率都很難畫上等號。

 

建構Domain-Specific Framework需要什麼技術？

 

  以.NET Framework平台而言，建構Domain-Specific Framework前，你至少得了解物件導向的繼承及封裝，還有介面的應用，這樣才不會撰寫多餘的程式碼。

為了提供合理的擴充性，你得學會Reflection的應用，它可以讓你動態的載入Assembly及黏接各個模組。

  為了提供合理的彈性，你得學會如何運用組態檔來改變Domain-Specific Framework的行為，以今日的顯學來說，你還得了解XML，運用它來撰寫及讀取組態檔。

在Multi-Tier的架構下，你得學會SOAP、JSON，並利用他們來做為各個Tier間通訊的訊息協定。

 

 

站在別人的肩膀上

 

  你也不一定要自己從頭來過，市面上有許多免費的Framework可以供建構Domain-Specific Framework用，例如當你想設計出可抽換的架構時，可以選擇MEF、Spring.Net Framework，

但請注意，這並不是不去了解前述那些技術的理由，因為要妥善運用他們，還是得先懂其內部是怎麼運作的。