我们为什么需要DTO(数据传输对象)
原文：http://www.cnblogs.com/Gyoung/archive/2013/03/23/2977233.html
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之间的转换，确实......代码要多很多，挺麻烦 的说。：
最新文章
- Android—判断当前时间段
- etc这个目录
- python子网拆分IP段
- 用emacs的org2blog组件写cnblogs博客 -- 环境配置及使用
- Java实现UDP之Echo客户端和服务端
- OpenCV中cvWaitKey()函数注意事项
- Balanced Lineup 倍增思想到ST表RMQ
- [转] ArcEngine 产生专题图
- 在 Linux 命令行中使用和执行 PHP 代码
- HTTPS背后的加密算法（转）
- 常用 SQL语句
- 51nod1119(除法取模)
- Java中的static、final关键字
- SQLServer之创建链接服务器
- margin居中显示
- ArcGis 制图——地图图框整饰的插件式实现（一）C#
- hadoop的job执行在yarn中内存分配调节————Container [pid=108284,containerID=container_e19_1533108188813_12125_01_000002] is running beyond virtual memory limits. Current usage: 653.1 MB of 2 GB physical memory used
- Mybatis的针对于同一个有自己父类或子类的递归查询 （如商品分类）
- css实现幻灯片播放效果
- Windows上Nginx的安装教程详解