目前的Web Application大多采用流行的基于B/S模式的三層架構開發(fā)，這里的三層架構指的就是Web層、業(yè)務層和數據訪問層。采用分層的開發(fā)方式有很多好處，下面只簡單地來說兩點：
1：分層開發(fā)使不同的開發(fā)人員關注他們擅長的特定層面，有助于開發(fā)優(yōu)質的系統(tǒng)。因為很少有程序員可以精通從JS，CSS，DHTML到struts再到 hibernate直至最后的數據庫設計這一整套開發(fā)流程所要使用到的所有技術。大家各司其職，全力關注自己擅長的層面，這要比一個人或一個小組負責某一模塊從頁面到最底層的開發(fā)方式要好的多。
2：.分層分離了邏輯，使得系統(tǒng)結構層次明晰，系統(tǒng)變得靈活和易于維護。開發(fā)人員應該盡量使系統(tǒng)的各層之間保持相對獨立的松耦合狀態(tài)，這是實現(xiàn)分層的必要條件，也是構建良構系統(tǒng)的重要保證。
下面重點說說在各層之間進行數據傳遞的問題。在討論這個問題之前我想有必要闡明幾個概念，即VO、PO、POJO、BO、DAO、DTO。
VO：值對象（Value Object），另外也有人認為VO指的是View Object，視圖對象，亦或者它就是表示兩個概念。
PO：持久化對象（Persistence Object）
POJO：（Plain Old Java Object）字面意思應該是無格式的傳統(tǒng)Java對象。對于這個概念我看網上有很多人都弄不明白，有的人甚至把它認為是PO，就我個人的理解，我認為 POJO是一個相對概念，就像它的字面意思一樣，它指的就一個普普通通的java對象，這一概念主要是用來和像java bean這樣遵從特定規(guī)范的java objcet進行區(qū)別而創(chuàng)造的。
BO：業(yè)務對象（Business Object），有人把BO理解成是業(yè)務層操縱的數據對象是不對的，BO指的是封裝了業(yè)務處理邏輯的對象（就是我們要在service層實現(xiàn)的那些類的實例）而業(yè)務層操縱的數據對象其實是VO。
DAO就不用多說了（Data Access Object）數據訪問對象，
DTO：（Data Transfers Object）數據傳輸對象。對于這個概念也是比較好理解的，Struts中的ActionForm其實就是一個DTO，用于在頁面和Action之間進行數據的傳遞。另外如果把VO理解成視圖對象的話，那么ActionForm就算是VO了。
網上好像還流傳一種叫做QO的對象，我想應該指的是（Query Object）查詢對象吧，不過我好像真沒怎么見過這東西。
弄明白上面幾個概念以后，我想說一下這兩天一直在考慮的問題，那就是各個層上操縱的數據對象以層與層這間的數據傳輸問題。
首先來看各層之間操縱的數據對象：
Web層（JSP/Action）：ActionForm
業(yè)務層：VO （注意：如果我們使用了Hibernate那么我可以使用它生成的PO來替代業(yè)務層的VO，這是因為從結構上講VO和PO幾乎沒有什么不同，而又由于 Hibernate的強大功能，使得它的PO可以可以離開持久化層而存在。要知道并不是所有ORM工具都具有這種能力：比如JDO1.x就不可以）
數據訪問層：PO。
下面是詳細的解說：
ActionForm是Web層的數據表示，他不能被傳遞到業(yè)務層。
PO是持久層的數據表示，在特定情況下，例如Hibernate中，他可以取代VO出現(xiàn)在業(yè)務層，但是不管PO還是VO都必須限制在業(yè)務層內使用，最多到達Web層的Control（即Action），絕不能被擴散到View去。ActionForm和PO之間的數據轉化是在Action中進行的。
其實放開來看，每一層都有自己特定的數據對象，而不是各層共用一種結構的數據對象，這樣的話各層之前將嚴重耦合。在彼此相臨的層之間，應該會有這么一個操作過程，即從它的上層或下層接收數據對象，并從中提取出需要的數據封裝進自己層要操縱的數據對象里。例如在Action中就是這樣做的，但由于業(yè)務層和數據訪問層使用了同一種數據訪問對象而省去了這種操作。
這里的焦點是Action，我們在Action要的做工作是：接受從頁面?zhèn)鱽淼腁ctionForm，從中取出數據，封裝到PO中，然后調用業(yè)務層組件（BO）實現(xiàn)相關業(yè)務，最后進行頁面跳轉。