從事Java Web開發這一段時間來，對Java 面向對象的思想和(hé)MVC開發模式可(kě)以說已經熟悉了。我當前參與的項目使用的框架是Spring、SpringMVC、Hibernate。作為剛剛參加工作的入門者，我下(xià)面談自己的幾點心得，還懇請前輩指正。

想必流行的做法都是把後台部分的代碼分為entity（或domain）、dao、service、web幾個(gè)層吧。

實體類

實體類就是對現實世界事物的建模，往往正是跟現實中(zhōng)的“實體”相對應，但也有些不是，隻是為了将數據封裝起來便于傳輸和(hé)表現（這一點，在做客戶端軟件時尤其如(rú)此，畢竟内存是相當有限的，拉出的數據最好全部用于表現，多餘就意味着浪費内存）。

我有個(gè)觀點：連接處是難點。Java代碼需要連接的有兩個(gè)：跟前台的頁面，即視圖相連接，這個(gè)靠web層；另外，就是跟數據庫相連接，這個(gè)靠的是entity層。而這兩個(gè)層相比，實體類又是更重要的，它就像是一幢大樓的地基。對實體類的設計，我感覺是一個(gè)項目的關(guān)鍵。要想設計好實體類，簡單的說，需要遠(yuǎn)見，具體地說，需要不僅僅理清項目業(yè)務邏輯，還需要有較豐富的開發經驗。因為理清業(yè)務邏輯，可(kě)能隻是能窮舉出所需要的實體以及它們直觀的屬性，但有時那些實體還需要拆分合并（以前參與過一個(gè)求職招聘網的項目，在建表時是把求職和(hé)招聘信息分開建的表，但到後來發現，在用戶登錄後需要呈現的是所有的信息，這下(xià)帶來了代碼的不小改動(dòng)），并且有些屬性雖然不那麼直觀，但卻是有必要的，常見的就是一些flag、status之類的屬性，這就需要在設計時就最好能預見到，不然在開發過程經常修改數據庫中(zhōng)的表結構，也會開發進度。

綜上，俗話說得好，磨刀不誤砍柴工，實體類設計好了，往上走，将勢如(rú)破竹。

另外，公司的做法是在實體類中(zhōng)建一個(gè)BaseObject作為一個(gè)項目中(zhōng)所有實體類的父類，定義幾個(gè)都要用到的成員變量，如(rú)id,version，createTime。這樣做，一方面減少(shǎo)了重複的代碼，另一方面，在設計後續的BaseDao時也很方便。

數據訪問(wèn)對象DAO

dao中(zhōng)的方法就是對數據庫中(zhōng)的數據進行“單純”的增删改查（之所以說單純，就是因為它并沒不牽涉業(yè)務），其中(zhōng)較複雜多變的是查找，這一點和(hé)sql語句是對應的。

對于DAO層，我們通(tōng)常的做法也是創建一個(gè)父類，即BaseDao, 并且使用Java 的泛型将BaseObject作為它要操作的數據類型，這樣，在不同實體類對應的DAO去繼承BaseDao時，就可(kě)以用各自的實體去替換BaseOject了（假如(rú)entity層沒有采用繼承BaseObject的模式，那麼可(kě)以用在BaseDao中(zhōng)可(kě)以用Object作占位符）。

這個(gè)BaseDao還可(kě)以繼承框架中(zhōng)已有的Dao,如(rú)HibernateDaoSupport，當然也可(kě)以自己寫。

在做求職招聘網時，我們就是自己寫的，形如(rú)：public class BaseDao<T, PK extends Serializable> ，特别注意：該類不由Spring管理。這裡邊有兩個(gè)難點：①如(rú)何獲取Hibernate中(zhōng)的session對象？可(kě)以采用注釋注入SessionFactory，通(tōng)過調用它的getCurrentSession方法獲取Session對象。②在編寫查詢方法時需要用到繼承BaseDao的dao類所對應的實體類的類型，如(rú)何動(dòng)态地獲取呢(ne)？比如(rú)當UserDao繼承BaseDao時，在BaseDao中(zhōng)如(rú)何動(dòng)态地獲知相應的實體類是User類型呢(ne)？這裡邊用到了反射和(hé)構造方法，由于子(zǐ)類在創建時會驅動(dòng)BaseDao的創建，所以在BaseDao中(zhōng)的構造方法中(zhōng)使用this關(guān)鍵字，和(hé)反射中(zhōng)的方法獲取子(zǐ)類泛型參數中(zhōng)第一個(gè)參數的類型，即為所需的entityClass

業(yè)務邏輯層Service層

業(yè)務邏輯層的方法就是對信息進行加工處理用的，業(yè)務邏輯層，顧名思義，就是根據業(yè)務對數據進行處理，主要通(tōng)過調用dao中(zhōng)的方法實現（看了一個(gè)帖子(zǐ)，鍊接地址為：http://www.iteye.com/topic/35907，說Service層的方法也可(kě)以互相調用）。業(yè)務層中(zhōng)的類往往都用事務管理，因為一個(gè)業(yè)務往往就是一個(gè)事務，比如(rú)銀行的轉賬業(yè)務，既要從一方扣錢，又要給另一方加錢，在扣錢和(hé)加錢的間隙出問(wèn)題了，事務就要回滾，不然是不合情理的。

在開發過程中(zhōng)我發現，大家的service層的方法，都和(hé)dao層差不多，甚至名字很多都一樣，反倒是把真正的業(yè)務處理都放在了web層。這樣做，我認為是很不科學的，web層是沒有事務控制的，一旦發生異常，就可(kě)能産生髒數據。因而還是應該把業(yè)務放在本來屬于它的位置上來。

發布層Web層

這又是一個(gè)連接處，它聯系的是http請求/響應和(hé)Java模型，是開發中(zhōng)的關(guān)鍵點。我現在的做法通(tōng)常是在有了實體類以後，從web層着手向下(xià)開發，比較喜歡點擊那個(gè)不存在的方法提示出的“creat method in xxxService/xxxDao”了，這樣開發非常有動(dòng)力，好像打一場圍殲戰，最後把敵人都消滅在了Dao層。

web層通(tōng)常是要調用Service中(zhōng)的方法完成的，它起到的作用是就是調度。與Service相比，web層該是瘦子(zǐ)，Service該是胖子(zǐ)。我的一點心得是：在web層中(zhōng)的一個(gè)方法中(zhōng)不宜調用多個(gè)涉及到更新數據的Service，但可(kě)以調用多個(gè)隻進行數據查詢的Service方法。這樣做，我想着也是怕發生異常時，同一個(gè)方法中(zhōng)某個(gè)事務已經提交，而另外一個(gè)事務卻沒有提交的情況出現。但是，如(rú)果确實在Service層中(zhōng)按照業(yè)務定義了方法，這種情況按說也不會出現，

其他想法

有一種聲音：說目前的Java Web開發是很沒技術(shù)含量的，因為有成熟的框架。這樣的說法對我是挺刺激的，畢竟，自己堂堂一個(gè)本科生，心底裡總還是想做點有技術(shù)含量的工作，我有個(gè)願望，想成為一名軟硬兼通(tōng)的工程師(shī)，大概也是基于這樣的觀念吧——技術(shù)含量。

我仿佛并沒有考慮自己是否感興趣，隻是覺得隻要努力，便能做到。道理我也懂，先把目前的工作搞好，既然從事的是軟件，就老老實實把軟件先做好。别人說的話，聽聽是對的，但還要想一想。我覺得，能把一個(gè)龐大的系統分析設計出來，能解決這中(zhōng)間出現一系列問(wèn)題，其實并不容易。有句話說得好，做好平凡事，你(nǐ)就不平凡。

最近的想法是如(rú)果覺得自己能勝任工作，那就換一個(gè)角度想一想，比如(rú)自己不依靠一些現成的東西（比如(rú)框架），也可(kě)以把自己想象成項目經理，看看自己是否有能力解決掉所有項目經理要處理的事情，如(rú)果不能，那就還是去練内功吧。

找一些有難度的事情給自己點挑戰，要保證自己一直在進步，一直在成長。