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

用一個(gè)例子來說明可能會(huì)比較容易理解：

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

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

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

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

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

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

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