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之间的转换，确实......代码要多不少，挺麻烦 的说。：