用幾句通俗的話，也就是比較官方的話給大家做一個簡單的解釋：

框架（Framework）的一種定義認為是整個或部分系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法。另一種定義認為，框架是可被應用開發者定制的應用骨架。前者是從應用方面，而後者是從目的方面給出的定義。

　　可以說，一個框架是一個可復用的設計構件，它規定了應用的體系結構，闡明了整個設計、協作構件之間的依賴關系、責任分配和控制流程，表現為一組抽象類以及其實例之間協作的方法，它為構件復用提供了上下文(Context)關系。因此構件庫的大規模重用也需要框架。

　　框架，其實就是某種應用的半成品，就是一組組件，供你選用完成你自己的系統。簡單說就是使用別人搭好的舞臺，你來做表演。而且，框架一般是成熟的，不斷升級的軟件。

　　軟件系統隨著業務的發展，變得越來越復雜，不同領域的業務所涉及到的知識、內容、問題非常非常多。如果每次都從頭開發，那都是一個很漫長的事情，且並不一定能做好。團隊協作開發時，沒有了統一標準，大家各寫各的，同樣的重復的功能到處都是。由於沒有統一調用規範，很難看懂別人寫的代碼，出現Bug或二次開發維護時，根本無從下手。

　　而一個成熟的框架，它是模板化的代碼，它會幫我們實現很多基礎性的功能，我們只需要專心的實現所需要的業務邏輯就可以了。而很多底層功能操作，就可以完完全全不用做太多的考慮，框架已幫我們實現了。這樣的話，整個團隊的開發效率可想而知。另外對於團隊成員的變動，也不用太過擔心，框架的代碼規範讓我們能輕松的看懂其他開發人員所寫的代碼。

　　一般來說，一個中小型項目，1到5人左右的開發團隊，使用一般的三層結構就可以了，不用去細想框架要分三層還是五層，每個層之間要怎麽實現解耦，要用什麽設計模式。因為當今飛速發展的互聯網時代，快才是王道。人工與時間成本才是重點中的重點，唯有快才能更好的生存下來並壯大。至於擴展功能、接口、分布式、並發、大數據等等問題，實際上過早考慮太多並不是好事情，還不如先做出來積累一定經驗後再慢慢學習，慢慢升級框架。

　　這裏為什麽說可以暫時理解為每個數據表對應一個實體？大家都知道，我們做系統的目的，是為用戶提供服務，用戶可不關心你的系統後臺是怎麽工作的，用戶只關心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那麽數據庫中也要有相應的增、刪、改、查，而增刪改查的具體操作對象就是數據庫中的數據，說白了就是表中的字段。所以，將每個數據表作為一個實體類，實體類封裝的屬性對應到表中的字段，這樣的話，實體在貫穿於三層之間時，就可以實現增刪改查數據了。

　　三層及實體層之間的依賴關系 如圖詳述：

　　最後向大家做一個小結：

　　　　框架（Framework）的一種是整個或部分系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法。

　　　　軟件架構（Software Architecture）是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計，是一個系統的草圖，描述的對象是直接構成系統的抽象組件、各個組件之間的連接，明確細致的描述組件之間的通訊。

　　　　框架具有代碼模板化、可重用、高內聚（封裝）、規範性、可擴展、可維護、協作開發和通用性的特點。

　　　　　　三層是指表現層、業務邏輯層和數據訪問層。

　　　　　　表現層（UI）：主要是指與用戶交互的界面；

　　　　　　業務邏輯層（BLL）：該層主要負責處理系統的業務邏輯，以及充當表現層與數據訪問層之間的橋梁，負責數據的傳遞和處理；

　　　　　　數據訪問層（DAL）：主要實對數據的增、刪、改、查。將存儲在數據庫中的數據提交給業務層，同時將業務層處理的數據保存到數據庫。

微軟分層代碼架構——簡述