系列文章目錄：
設計自己的應用開發框架二(體系結構)
設計自己的應用開發框架三(數據操作與業務實體)
設計自己的應用開發框架四(業務類庫與業務邏輯)
設計自己的應用開發框架五(插件編寫與用戶界面)
設計自己的應用開發框架六(異常與日誌)
設計自己的應用開發框架七(國際化)
設計自己的應用開發框架八(插件化)
在上一篇作爲引子的文章中，我一遍遍的問大家是不是應該需要一個自己的應用開發框架。如果您還能讀系列文章的第二部分，也就是您現在所看到的這個小文，那麼就說明您的回答是肯定的。那麼這個定製框架應該是個什麼樣子呢？它是否真的能夠帶給我們那些好處呢？在本文中，我們將逐步瞭解它的體系結構。
下面這個圖形是一個典型的三層結構模型，這也是我們日常開發過程中最常見的模型。當然，您可以進一步的將它進行細分，以達到想要的分層效果。不過，這並不影響我們對框架的使用，也並不影響我們拿三層結構來說事兒。
上圖概括的說明了，框架所位於的位置，以及它的作用。協調軟件項目中各層之間的工作，並對整個工程進行有效的控制和代碼重用是其最根本的用途。
那麼如何來進行這些工作呢？下面這張圖將整個定製框架的內部結構進行了細分。當然，這只是我目前項目中的細分，並不意味着您的定製框架也要這個樣子。
由上圖可以看出，通過定製框架的幫助，我們能在不同的層次獲得各自需要的支持模塊。
在業務實體部分(BusinessEntity)，我們可以爲實體層封裝可能用到的數據連接方式，當然在實際的開發過程中我們可以只封裝一個就夠了。同時我們還要在其中定義常用的數據操作方法，接着我們要爲整個業務實體部分制定規則、優化等（在本系列文章的第三部分將會詳細介紹）
在業務邏輯部分(BusinessLogic)，我們爲該層提供界面到實體的業務傳遞控制，以及安全等常用方法。（系列文章第四部分）。
在界面部分(UI)，我們爲界面層提供界面擴展、報表、編輯器等功能（系列文章第五部分）。
這裏我們還有兩個基礎模塊貫穿整個框架的始終，那就是自定義異常和日誌部分，它們負責爲框架捕獲自定義的異常以及發生異常或需要調試時日誌的輸出功能（系列文章第六部分）。
到這裏，相信您已經明白我們如何通過編寫定製框架使反覆的開發過程變得簡化了。因爲在我們所進行的大多數開發過程中，只有圖中深藍色部分會發生一些改變，而其它部分是基本不變的。所以，一旦我們擁有了適合自己的開發框架，以後的工作將變得更加的容易和敏捷化。