既然DTO是展示層與服務(wù)層之間傳遞數(shù)據(jù)的對象，為什么還需要一個VO呢？對！對于絕大部分的應(yīng)用場景來說，DTO和VO的屬性值基本是一致的，而且他們通常都是POJO，因此沒必要多此一舉，但不要忘記這是實現(xiàn)層面的思維，對于設(shè)計層面來說，概念上還是應(yīng)該存在VO和DTO，因為兩者有著本質(zhì)的區(qū)別，DTO代表服務(wù)層需要接收的數(shù)據(jù)和返回的數(shù)據(jù)，而VO代表展示層需要顯示的數(shù)據(jù)。

用一個例子來說明可能會比較容易理解：

例如Service層有一個getUser的方法返回一個系統(tǒng)用戶，其中有一個屬性是gender(性別)，對于Service層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會反駁，在服務(wù)層直接就返回“帥哥美女”不就行了嗎？對于大部分應(yīng)用來說，這不是問題，但設(shè)想一下，如果需求允許客戶可以定制風格，而不同風格對于“性別”的表現(xiàn)方式不一樣，又或者這個服務(wù)同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現(xiàn)層的要求有所不同，那么，問題就來了。再者，回到設(shè)計層面上分析，從職責單一原則來看，服務(wù)層只負責業(yè)務(wù)，與具體的表現(xiàn)形式無關(guān)，因此，它返回的DTO，不應(yīng)該出現(xiàn)與表現(xiàn)形式的耦合。
理論歸理論，這到底還是分析設(shè)計層面的思維，是否在實現(xiàn)層面必須這樣做呢？一刀切的做法往往會得不償失，下面我馬上會分析應(yīng)用中如何做出正確的選擇。

VO與DTO的應(yīng)用
上面只是用了一個簡單的例子來說明VO與DTO在概念上的區(qū)別，本節(jié)將會告訴你如何在應(yīng)用中做出正確的選擇。

在以下才場景中，我們可以考慮把VO與DTO二合為一（注意：是實現(xiàn)層面）：

當需求非常清晰穩(wěn)定，而且客戶端很明確只有一個的時候，沒有必要把VO和DTO區(qū)分開來，這時候VO可以退隱，用一個DTO即可，為什么是VO退隱而不是DTO？回到設(shè)計層面，Service層的職責依然不應(yīng)該與View層耦合，所以，對于前面的例子，你很容易理解，DTO對于“性別”來說，依然不能用“帥哥美女”，這個轉(zhuǎn)換應(yīng)該依賴于頁面的腳本（如JavaScript）或其他機制（JSTL、EL、CSS）
即使客戶端可以進行定制，或者存在多個不同的客戶端，如果客戶端能夠用某種技術(shù)（腳本或其他機制）實現(xiàn)轉(zhuǎn)換，同樣可以讓VO退隱

以下場景需要優(yōu)先考慮VO、DTO并存:

因為某種技術(shù)原因，比如某個框架（如Flex）提供自動把POJO轉(zhuǎn)換為UI中某些Field時，可以考慮在實現(xiàn)層面定義出VO，這個權(quán)衡完全取決于使用框架的自動轉(zhuǎn)換能力帶來的開發(fā)和維護效率提升與設(shè)計多一個VO所多做的事情帶來的開發(fā)和維護效率的下降之間的比對。

如果頁面出現(xiàn)一個“大視圖”，而組成這個大視圖的所有數(shù)據(jù)需要調(diào)用多個服務(wù)，返回多個DTO來組裝（當然，這同樣可以通過服務(wù)層提供一次性返回一個大視圖的DTO來取代，但在服務(wù)層提供一個這樣的方法是否合適，需要在設(shè)計層面進行權(quán)衡）。