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