本框架是針對資料庫應用軟體的。顧名思義，資料庫應用軟體是圍繞資料庫展開的，對資料庫的操作，無非是查詢、增加、刪除、修改、儲存，分別對應sql中的select、insert、delete、update、commit。資料庫應用軟體從本質上來說，就是將用視覺化的介面讓普通使用者去執行這些sql，當然，這些sql不是隨便就可以執行的，要遵循一定的規則，這就是業務邏輯。
所以，介面、業務邏輯、資料庫構成了資料庫應用程式。怎樣去組織這三者就是本文要討論的問題。
模式是解決乙個特定問題的最佳方案，所以我們的任務就是設計出乙個組織介面、業務邏輯、資料庫的模式。
提起模式，自然會想起大名鼎鼎mvc，mvc是組織模型、檢視、控制器的最佳方案，而我們的任務中，也是三個核心型別，能否直接用mvc解決呢？
顯然介面對應檢視，資料庫對應模型，那麼業務是否也與控制器對應呢？控制器決定介面對使用者輸入的響應方式，顯然業務邏輯並不能與控制器對應。但在我們的框架中引入mvc顯然也是乙個好方案，我們可以另外引入控制器，但現在的問題是如何處理業務？
將業務放到介面中顯然不是好主意，在此就不討論了。那麼能不能將業務放到實體裡面呢？在討論這個問題前先要對實體做乙個定義。
在一些書中，實體定義為對應表中的一行資料，可是我們經常要同時處理多條資料，如主從表中，乙個主表中的行往往對應從表中的多行，按前面的定義，做乙個涉及主從表的業務可能涉及多個從表實體，這樣是不是值得呢？
根據我的實踐經驗，把定義換乙個字就可以了，實體定義為對應表中的一組資料。按照這樣的定義，乙個主表中的行對應的從表中的多行可以放到乙個從表實體中去。
我們再回到前面的問題，業務是不是要放到實體裡？回憶我做的專案，資料庫結構一旦確定後很少修改，但業務邏輯卻經常變化，一般情況下，所謂的需求變更都是業務邏輯的變更。根據「封裝變化」的原則，業務與實體應該分開。
至此，我們的框架中有了四個核心型別：介面、控制器、實體、業務邏輯。我們還需要引入最後乙個型別，即實體工廠。
在物件導向的程式中，物件的建立和銷毀其實是很麻煩的一件事，也非常消耗資源。其中最典型的就是實體，一般實體建立時需要從資料庫中取資料填充到自己的例項變數中，銷毀時需要銷毀這些例項變數。在寫程式時，如果有多個分支，往往會在某個分支中忘記了銷毀，從而造成記憶體洩漏。另外，每次實體建立時都需要訪問資料庫取資料，對資料庫也是乙個不小的負擔。我們可以思考一下，如果我們嚴格遵循oo，對資料庫的訪問都通過實體，如果實體已經建立，我們只需要到實體中取資料就可以了，根本不需要再去訪問資料庫。很雖然，我們需要乙個快取，我把這個任務分配給了「實體工廠」。實體就是實體工廠的產品。
下面的問題就是實體與實體工廠如何對應，在現實世界中，乙個工廠會生產多個產品，所以我們的軟體中也可以這樣做。事實上筆者的框架的第乙個版本就是這樣做的，但實踐後改為「一一對應」，即乙個實體工廠只有乙個實體產品。
至此，我們框架中的五個核心型別就全部形成了，即介面、控制器、實體工廠、實體、業務邏輯。
它們的關係如下：
圖中除了這五個型別外，還有乙個資料庫，後面會有解釋。
五個型別的職責和關係如下： 型別
職責
管理者 介面
與使用者互動
從資料庫中檢索資料
將使用者的操作恢**送給控制器
使用者操作
控制器
接受介面的呼叫，轉呼叫後台
控制事務
控制介面的跳轉
單例，應用程式負責銷毀
實體工廠
建立實體
快取實體
銷毀實體
單例，應用程式負責銷毀 實體
與資料庫互動
實體工廠 業務
實現業務邏輯
無，區域性變數，自動例項化
如果嚴格按mvc中v的定義，介面應該是沒有業務邏輯的，也不應該與資料庫直接互動。在我的第乙個版本中，確實是這樣做的。但這樣做的結果是很累。在我們的資料庫中，往往有很多**與意義的對應，在表中，往往只是儲存**，在乙個資料字典表中，儲存**的意義，在介面中，往往要顯示意義而不是**。而實體一般與表對應，它其中儲存的只能是**，如果介面不直接訪問資料庫，要想在介面中顯示意義是很麻煩的。所以，現在的版本中，介面是可以直接訪問資料庫的，但只有讀而不能寫。
另外，介面中有輸入檢查的功能，如輸入乙個不存在的資料，會彈出乙個查詢介面列出合法的資料供使用者選擇。在最初的版本中，這個功能也是放到控制器來做的，同樣做得很累。現在的版本中把這個功能也放到介面中去了。
一般情況下，只是把使用者的介面的操作轉化為對後台的呼叫，嚴格來說，控制器不應該實現業務邏輯，但在實踐時，我發現有些業務邏輯也可以放到控制器中，這些業務邏輯有兩個條件：
業務邏輯比較簡單，如果用乙個專門的業務類去處理有些「大材小用」
此業務邏輯沒有重用性，只有在當前控制器服務的介面中才會呼叫到。
另外，控制器還有控制事務的作用。業務類和實體類是不會提交或回滾事務的，這個任務由控制器來負責。需要說明的是，如果沒有介面（也就沒有控制器），如在後台執行的一些服務，這時的事務就由實現此服務的業務類來控制。
實體只是負責對資料庫的訪問，也不會包含業務邏輯。實體只負責其自身相關的資料庫表的訪問。在我的最初版本中，實體是包含業務邏輯的，但在實踐中漸漸放棄了這種做法。
一步一步寫演算法（開篇）
演算法是計算機的生命。沒有演算法，就沒有軟體，計算機也就成了乙個冰冷的機器，沒有什麼實用價值。很多人認為，演算法是數學的內容，學起來特別麻煩。我們不能認為這種觀點是錯誤的。但是我們也知道，軟體是一種復合的技術，如果乙個人只知道演算法，但是不能用程式語言很好地實現，那麼再優秀的演算法也不能發揮作用。乙...
一步一步寫演算法（開篇）
演算法是計算機的生命。沒有演算法，就沒有軟體，計算機也就成了乙個冰冷的機器，沒有什麼實用價值。很多人認為，演算法是數學的內容，學起來特別麻煩。我們不能認為這種觀點是錯誤的。但是我們也知道，軟體是一種復合的技術，如果乙個人只知道演算法，但是不能用程式語言很好地實現，那麼再優秀的演算法也不能發揮作用。乙...
一步一步寫演算法（開篇）
一步一步寫演算法 開篇 演算法是計算機的生命。沒有演算法，就沒有軟體，計算機也就成了乙個冰冷的機器，沒有什麼實用價值。很多人認為，演算法是數學的內容，學起來特別麻煩。我們不能認為這種觀點是錯誤的。但是我們也知道，軟體是一種復合的技術，如果乙個人只知道演算法，但是不能用程式語言很好地實現，那麼再優秀的...