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

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

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

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

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

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

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

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

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

　　最後向大家做一個小結：

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

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

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

　　　　　　三層是指表現層、業務邏輯層和資料訪問層。

　　　　　　表現層（UI）：主要是指與使用者互動的介面；

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

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