POJO(plain old java Object)[譯：簡單初始Java對象]。它簡單(因為只有set/get方法)嗎？或是我們把應該把它弄得復雜點(帶點業(yè)務判斷)？究竟它在我們J2EE應用中扮演一個什么樣的角色呢？一個Anemic Domain Model，Rich Domain Model, DTO, O/R mapping Entity........！以前我的系統(tǒng)中POJO都是一個貧血的模型，只有set/get方法！它的職責就是把前端頁面的數(shù)據(jù)從formBean中轉(zhuǎn)移過來(用反射)，作為持久層的對象。這里POJO有兩個角色，一個角色是傳送數(shù)據(jù)，另一個是角色是PO(持久對象)。一段時間后我發(fā)現(xiàn)這樣做效率低下，想像一下有些業(yè)務處理，如一個銀行帳戶的pojo,里面有一個金額和利息字段，這個金額是通過一些公式計算后得出來的，開始時我們在業(yè)務層里把金額算出來后set到帳戶pojo金額字段里。我開始思索把一些都是計算或者純邏輯的東西pull Up到pojo中。這時候我的pojo變成一個Domain Object。盡管不是一個Rich的Domain Model,但畢竟前進了一小步。再后來用到了webwork2,由于webwork2里沒有了struts formBean，使用攔截機設值，ModelDriven模式下我的持久Entity就是一個formBean和po的結(jié)合,　在ACTIO中它是一個有值的VO，在DAO實現(xiàn)層變成一個PO。在這里我的pojo繼承了O/R Entity類，并把合適的業(yè)務層的代碼都移到相應的了Pojo中，當然沒有持久層的代碼。這樣我的系統(tǒng)的部分pojo變成了Rich Domain Model。在Ejb下，由會話門面管理對POJO業(yè)務對象訪問對比起笨重的entity bean有更高的效率和可移植性。盡管Ejb下的POJO不能享受entity bean的CMP策略，但有了spring 的IOC后，一切變得可配置了！POJO還有很重要的一個優(yōu)勢就是pojo中的業(yè)務可以脫離具體容器運行測試！在這里,pojo是貧血還是沖血應該取決于你的業(yè)務應用，記住：不要把簡單的問題搞復雜了，但把復雜的問題分解成簡單的問題一直就是我們追求的！