引子
網友問：
很多的參考書目中都是把對資料庫的操作都是獨立於文件類封裝成資料庫類。基本上是對應一個表就要建立一個類，在其中實現“增、刪、改、差”的功能。程式碼看起來比較龐大，當然通過類的劃分模組比較的清楚，使用時通過資料庫類的物件的簡單的函式呼叫就可以了。（不用傳完整的SQL語句，僅僅是用到的引數而已）

按照OO的思想，我也感覺書上的方法要合理一些，但是就是太麻煩了，還是傳SQL語句的方法比較習慣一些。

各位高手們、你們一般是怎麼處理的、隨便說說這樣處理的好處。謝謝！

作者答：
我也同意書上的做法。目前我們專案涉及到的資料庫比較簡單，因此一般我都封裝到一個類中。類的成員變數只有一個，那就是資料庫連線m_pConnection。其它的都是函式。如果資料庫比較複雜的話，我會派生一些子類用於處理不同的表。
這樣封裝的最大好處，我認為是開發方便，可以說是實現了三層模式：將介面、資料庫介面和資料庫開發完全分開，做介面的人不用關心資料庫，只需要呼叫相應的介面函式就可以了。作資料庫介面的人只需要關心封裝類中與資料庫的互動就可以了，做資料庫的人只需要做好儲存過程，觸發器之類的就可以了。這樣可以並行開發，提高效率

網友問：
比較困惑點的就是如果分工分明確的話、嚴格按照三層模式的結構來作並且的確分工比較明確的話這樣肯定是有好處的。

但是實際的開發過程中，我所遇到的是資料庫的結構要自己設計、儲存過程和觸發器也要自己寫。程式碼中對資料庫的操作也都是自己寫的。就是UI層、控制層、業務邏輯層也都是自己寫的。寫成類的話感覺負擔比較大。一個一個的寫類反而感覺給自己增添麻煩呀。這樣劃分不知道還有沒有什麼特別值得提倡或有益處的地方！！

請大俠在隨便討論一些，謝謝！

作者答：
你這個問題是一般的程式設計人員都會想到的。做這麼多類，好像有點重複性的工作啊。但是，我們要想到的是程式的可重用性和可維護性。雖然我們開發時有些負擔，但是以後的升級維護將非常方便。否則，以後的升級維護將是非常困難的事情。這一點必須注意。
只要我們將三層之間的介面預先定義好，這樣就相當於我們將專案拆分成了三個零件，零件之間的介面已經定義好了，那麼剩下的只需要三個零件分別開發了。如果那個零件以後要升級或者修改，那麼涉及範圍將只是這個零件而已。否則，你修改一個功能，可能的影響範圍將很大，造成升級和維護的困難。
類的好處就是封裝性，內部的問題與外界無關，這就是它的好處。所以定義類的時候，我的建議是不要定義公共的成員變數。所有成員變數都是私有或者保護性，增加Get/Set介面。這樣做，可能又會向你所說，是不是太麻煩一點了？但如果你考慮到以後維護的方便，這點工作還是值得去做的。
我們的專案為什麼做不好，問題不在第一次開發的時候，而是當用戶需求有所變更，程式有錯誤發生時，我們的程式缺乏靈活性，往往導致程式的很多部分要重做。因此，可維護性和可重用性是非常重要的。