---

科普一下。目前在這一塊，已經有代碼生成器了。

比如，根據資料庫中建立好的表，來創建模型，從而自動生成操作代碼。

在這一塊，我所瞭解的最先進的是VS（Visual Studio），它支持全圖形化的建模。你只需在VS裏輕點滑鼠，建好模型，然後VS會自動根據模型，去MSSQL（Microsoft SQL Server）中建表，以及創建相應的操作代碼。此時，你只需喝上一杯咖啡，等VS完成工作後，開車回家，玩老婆，鬧孩子。深夜，陪妻入睡。此時，其他語言狗、Linux語言狗們打來電話：我們還在寫sql建表，你怎麼回家睡覺了？

呵呵，開個玩笑。

現在很多UML建模工具，都支持圖形化建模。建模後，能自動生成資料庫表，以及操作代碼。但我們也要看到這些自動化工具的缺點：性能低。如果追求極端的性能，那麼你必須自己根據需求，來設計專用的資料庫訪問方式。

---

看業務場景，比如最常見的增刪改查，寫一個萬能資料庫操作類確實一勞永逸，大大減少後端工程師的工作量，甚至有些喪心病狂的後端工程師把資料庫增刪改查操作萬能類直接封裝給前端讓前端無障礙調用，如果你有稍微複雜點的需求要後端給你做介面，後端一怒之下直接把查sql介面暴露給你調用。這下後端真是一勞永逸了。。。。。話說這個介面寫完後端就可以失業了。

以上只是某些極端情況，大家不要效仿。因為這樣做會帶來很多新問題，比如前端不會寫SQL啦，或者寫的SQL效率太低，安全問題等。不過最主要的還是效率問題，很多時候一個業務流程不是一個SQL就能搞定的，此時大量的時間會浪費在前後端的數據傳輸上。

如果不涉及前端，只討論後端的話，每個表封裝一次實在無必要，但要是寫個萬能操作類的話又很容易因為對各個表的瞭解程度不同導致人為出錯大大降低開發速度，所以還是建議大家不要做造輪子的事情，很多持久化框架已經很好的解決了這些問題。不過個人覺得如果追求效率的話還是直接寫SQL吧

---

一般不用自己寫這些。很多框架會根據數據定義自動生成訪問封裝甚至底層的sql。

如果不想使用資料庫中間件，建議將底層數據操作和對象邏輯儘可能分離——當然，具體得考慮你的業務場景，是否需要擴展性以應對業務變化等因素。

---

建議寫一個萬用的資料庫增刪改查DAO，然後每個實體DAO繼承其。再每個實體使用其DAO寫一個業務級操作層，具體特化相應實體的業務讀寫要求。

---

有是有。譬如hibernate 的template。不過這樣做是滿足不了需求的。一個萬能的類，同時違背了ISP和SRP兩條原則，在OOD裏可以當作一個anti-pattern。

---

所有獨立的非業務功能都應該封裝復用，比如你在項目中要使用發郵件功能，那就把發郵件封裝成一個函數，那業務中需要發郵件只需調用一個函數即可，即使給項目其他人用他也不必關心底層是如何實現的。所以剛入門也應該造個輪子，這樣你在使用中就會發現輪子的不足並慢慢改進他。

---

推薦每個表對應一個dao，因為一個表的存在，或多或少都會有自己的業務需求是通用的orm解決不了的。要做漂亮的分層，又要儘可能的不在上層拼裝sql語句。

---

推薦閱讀：