VO與DTO的區別
既然DTO是展示層與服務層之間傳遞數據的對象，爲什麼還需要一個VO呢？對！對於絕大部分的應用場景來說，DTO和VO的屬性值基本是一致的，而且他們通常都是POJO，因此沒必要多此一舉，但不要忘記這是實現層面的思維，對於設計層面來說，概念上還是應該存在VO和DTO，因爲兩者有着本質的區別，DTO代表服務層需要接收的數據和返回的數據，而VO代表展示層需要顯示的數據。
用一個例子來說明可能會比較容易理解：
例如Service層有一個getUser的方法返回一個系統用戶，其中有一個屬性是gender(性別)，對於Service層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對於展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“祕密”代表未指定。說到這裏，可能你還會反駁，在服務層直接就返回“帥哥美女”不就行了嗎？對於大部分應用來說，這不是問題，但設想一下，如果需求允許客戶可以定製風格，而不同風格對於“性別”的表現方式不一樣，又或者這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對於表現層的要求有所不同，那麼，問題就來了。再者，回到設計層面上分析，從職責單一原則來看，服務層只負責業務，與具體的表現形式無關，因此，它返回的DTO，不應該出現與表現形式的耦合。
理論歸理論，這到底還是分析設計層面的思維，是否在實現層面必須這樣做呢？一刀切的做法往往會得不償失，下面我馬上會分析應用中如何做出正確的選擇。
VO與DTO的應用
上面只是用了一個簡單的例子來說明VO與DTO在概念上的區別，本節將會告訴你如何在應用中做出正確的選擇。
在以下才場景中，我們可以考慮把VO與DTO二合爲一（注意：是實現層面）：
當需求非常清晰穩定，而且客戶端很明確只有一個的時候，沒有必要把VO和DTO區分開來，這時候VO可以退隱，用一個DTO即可，爲什麼是VO退隱而不是DTO？回到設計層面，Service層的職責依然不應該與View層耦合，所以，對於前面的例子，你很容易理解，DTO對於“性別”來說，依然不能用“帥哥美女”，這個轉換應該依賴於頁面的腳本（如JavaScript）或其他機制（JSTL、EL、CSS）
即使客戶端可以進行定製，或者存在多個不同的客戶端，如果客戶端能夠用某種技術（腳本或其他機制）實現轉換，同樣可以讓VO退隱
以下場景需要優先考慮VO、DTO並存:
因爲某種技術原因，比如某個框架（如Flex）提供自動把POJO轉換爲UI中某些Field時，可以考慮在實現層面定義出VO，這個權衡完全取決於使用框架的自動轉換能力帶來的開發和維護效率提升與設計多一個VO所多做的事情帶來的開發和維護效率的下降之間的比對。
如果頁面出現一個“大視圖”，而組成這個大視圖的所有數據需要調用多個服務，返回多個DTO來組裝（當然，這同樣可以通過服務層提供一次性返回一個大視圖的DTO來取代，但在服務層提供一個這樣的方法是否合適，需要在設計層面進行權衡）。