目前的Web Application大多采用流行的基於B/S模式的三層架構開發，這裡的三層架構指的就是Web層、業務層和資料訪問層。採用分層的開發方式有很多好處，下面只簡單地來說兩點：

（1）   分層開發使不同的開發人員關注他們擅長的特定層面，有助於開發優質的系統。因為很少有程式設計師可以精通從JS，CSS，DHTML到struts再到hibernate直至最後的資料庫設計這一整套開發流程所要使用到的所有技術。大家各司其職，全力關注自己擅長的層面，這要比一個人或一個小組負責某一模組從頁面到最底層的開發方式要好的多。

（2）   分層分離了邏輯，使得系統結構層次明晰，系統變得靈活和易於維護。開發人員應該儘量使系統的各層之間保持相對獨立的鬆耦合狀態，這是實現分層的必要條件，也是構建良構系統的重要保證。

下面重點說說在各層之間進行資料傳遞的問題。在討論這個問題之前我想有必要闡明幾個概念，即VO、PO、POJO、BO、DAO、DTO。

（1）   VO：值物件（Value Object），另外也有人認為VO指的是View Object，檢視物件，亦或者它就是表示兩個概念。

（2）   PO：遲久化物件（Persistence Object）

（3）   POJO：（Plain Old Java Object）字面意思應該是無格式的傳統Java物件。對於這個概念我看網上有很多人都弄不明白，有的人甚至把它認為是PO，就我個人的理解，我認為 POJO是一個相對概念，就像它的字面意思一樣，它指的就一個普普通通的java物件，這一概念主要是用來和像java bean這樣遵從特定規範的java objcet進行區別而創造的。

（4）   BO：業務物件（Business Object），有人把BO理解成是業務層操縱的資料物件是不對的，BO指的是封裝了業務處理邏輯的物件（就是我們要在service層實現的那些類的例項）而業務層操縱的資料物件其實是VO。

（5）   DAO就不用多說了（Data Access Object）資料訪問物件，

（6）   DTO：（Data Transfers Object）資料傳輸物件。 對於這個概念也是比較好理解的，Struts中的ActionForm其實就是一個DTO，用於在頁面和Action之間進行資料的傳遞。

（7）   另外如果把VO理解成檢視物件的話，那麼ActionForm就算是VO了。網上好像還流傳一種叫做QO的物件，我想應該指的是（Query Object）查詢物件吧，不過我好像真沒怎麼見過這東西。

弄明白上面幾個概念以後，我想說一下這兩天一直在考慮的問題，那就是各個層上操縱的資料物件以層與層這間的資料傳輸問題。

各層之間操縱的資料物件：

（1）   Web層（JSP/Action）：ActionForm　

（2）   業務層：VO（注意：如果我們使用了Hibernate那麼我可以使用它生成的PO來替代業務層的VO，這是因為從結構上講VO和PO幾乎沒有什麼不同，而又由於Hibernate的強大功能，使得它的PO可以可以離開持久化層而存在。要知道並不是所有ORM工具都具有這種能力：比如JDO1.x就不可以）

（3）   資料訪問層：PO。

下面是詳細的解說：

（1）   ActionForm是Web層的資料表示，他不能被傳遞到業務層

（2）   PO是持久層的資料表示，在特定情況下，例如Hibernate中，他可以取代VO出現在業務層，但是不管PO還是VO都必須限制在業務層內使用，最多到達Web層的Control（即Action），絕不能被擴散到View去。

（3）   ActionForm和PO之間的資料轉化是在Action中進行的。

其實放開來看，每一層都有自己特定的資料物件，而不是各層共用一種結構的資料物件，這樣的話各層之前將嚴重耦合。在彼此相臨的層之間，應該會有這麼一個操作過程，即從它的上層或下層接收資料物件，並從中提取出需要的資料封裝進自己層要操縱的資料物件裡。例如在Action中就是這樣做的，但由於業務層和資料訪問層使用了同一種資料訪問物件而省去了這種操作。

這裡的焦點是Action，我們在Action要的做工作是：接受從頁面傳來的ActionForm，從中取出資料，封裝到PO中，然後呼叫業務層元件（BO）實現相關業務，最後進行頁面跳轉。