关于DAO和DTO的区别

DAO：数据访问对象（Data Access Object）。提供访问数据库的接口，或者持久化机制，而不暴露数据库的内部详细信息。DAO提供从程序调用到持久层的匹配。

DTO(data transfer object)：数据传输对象，作用仅在于在应用程序的各个子系统间传输数据，在表现层展示。与POJO对应一个数据库实体不同，DTO并不对应一个实体，可能仅存储实体的部分属性或加入符合传输需求的其他的属性。 

DTO数据传输对象，它可看做经处理的PO，可能增加或者减少PO的属性，在阅读很多开源框架源码的时候发现有很多是专门定义DTO层来绑定表现层中数据，那为什么不直接用实体模型呢，有了DTO还要考虑DTO和Model层之间的映射关系，那它是多余的吗？答案是否定的，举个栗子：

比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO 。

DTO是表示数据的对象，但是其中不包含任何业务逻辑，表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它 的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于 数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样 做会直接将领域对象的行为暴露给表现层。

需要了解的是，数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer领域对象可能会包含一些诸如CustomerId，CustomerName, Email, Address等信息。但如果UI上肯定不想向外界展示客户端地址信息，那么此时就需要CustomerDTO来实现，用CustomerDTO来重新定义主要在UI上展示的属性，无需展示Address地址这个属性了。

简单来说Model面向业务，我们是通过业务来定义Model的。而DTO是面向界面UI，是通过UI的需求来定义的。通过DTO我们实现了表现层与Model之间的解耦，表现层不引用Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改Model而不需要去改表现层中的东西。

以上是我对DAO和DTO两者的理解。