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