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

想必流行的做法都是把后臺部分的代碼分為entity（或domain）、dao、service、web幾個層吧。

實體類

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

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

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

另外，公司的做法是在實體類中建一個BaseObject作為一個項目中所有實體類的父類，定義幾個都要用到的成員變量，如id,version，createTime。這樣做，一方面減少了重復的代碼，另一方面，在設計后續(xù)的BaseDao時也很方便。

數據訪問對象DAO

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

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

這個BaseDao還可以繼承框架中已有的Dao,如HibernateDaoSupport，當然也可以自己寫。

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

業(yè)務邏輯層Service層

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

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

發(fā)布層Web層

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

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

其他想法

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

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

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

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