DTO之豁然開朗

緣起

• 基礎不穩，隨着年齡徒增加，才明白DTO，早上看了篇公衆號。http://mp.weixin.qq.com/s/mPkh1mgOrhmJWuc5QGwlew 忽然就明白3年前第一家公司爲何要來回轉換VO（DTO） PO這玩意，當時不理解問來問去，說操做數據庫PO不能直接操做。如今確實是才明白......
• 工做3年努力3年才發現起點過低，基礎不穩，努力考研.....，但願之後能不後悔
• 還好過了迷茫期，如今都比較冷靜堅信真理努力會有回報，念念不忘，必有迴響。
• 跨越年齡的理解甚不容易，哪怕是一個DTO理解也須要時間的沉澱，更別提其餘社會，家庭的互相理解了....
• 不僅是計算機了，真但願之後能找到辦法，不用經歷時間的流逝，一眼看穿本質......唉

DTO(數據傳輸對象)

• DTO即數據傳輸對象(Data Transfer Object)。以前不明白有些框架中爲何要專門定義DTO來綁定表現層(頁面)中的數據，爲何不能直接用領域模型(domain object)呢，有了DTO同時還要維護DTO與Model之間的映射關係，多麻煩。

摘兩個比較有意義的段落。

• 表現層與應用層之間是經過數據傳輸對象（DTO）進行交互的，數據傳輸對象是沒有行爲的POCO對象，它的目的只是爲了對領域對象進行數據封裝，實現層與層之間的數據傳遞。爲什麼不能直接將領域對象用於數據傳遞？由於領域對象更注重領域，而DTO更注重數據。不只如此，因爲「富領域模型」的特色，這樣 作會直接將領域對象的行爲暴露給表現層。

• 需 要了解的是，數據傳輸對象DTO自己並非業務對象。數據傳輸對象是根據UI的需求進行設計的，而不 是根據領域對象進行設計的。好比，Customer 領域對象可能會包含一些諸如FirstName, LastName, Email, Address等信息。但若是UI上不打算顯示Address的信息，那麼CustomerDTO中也無需包含這個 Address的數據

• 簡單來講Model面向業務，咱們是經過業務來定義Model的。而DTO是面向界面UI，是經過UI的需求來定義的。經過DTO咱們實現了表現層 與Model之間的解耦，表現層不引用Model，若是開發過程當中咱們的模型改變了，而界面沒變，咱們就只須要改Model而不須要去改表現層中的東西。

經典場景

• 實體模型變化的可能性比較的大！尤爲是在一期 轉到 二期， 二期轉到三期 以及前期發現實體設計可能存在不合理的狀況。 這個時候咱們須要修改實體！ 因爲咱們的實體在不少層次上都用了，那麼每修改一次實體，可能其餘不少地方都須要變動。 可是引入了DTO對象，這個變得不一樣了，實體的變動，我只須要變動實體與DTO的轉換過程。 好比說，原本有Item與ItemDTO對象，下一個時候我發現Item對象中許多字段存在冗餘，實體設計得很差，可能須要拆分！那麼若無ItemDTO，上層邏輯直接依賴於Item實體的話，須要將依賴的地方都進行修改。 如有ItemDTO，上層 只依賴於 ItemDTO，而不依賴於Item實體，這樣，咱們只須要想辦法修改 將ItemDTO與變動後的若干個實體進行正確轉換。上層 不須要動任何代碼 的說。 不過這樣寫，多了一個DTO與Pojo以及VO之間的轉換，確實......代碼要多不少，挺麻煩 的說。：