DTO产生背景

当我们在设计面向对象接口的时候，好的实践是在一个对象中隐藏很多信息，并提供一组细粒度的方法来访问和操作这些信息，这意味着每个方法都应该负责单个、细粒度的、原子化的功能。这种方法从对象内部提供了很好的抽象，并增加了方法重用的可能性，这样做需要写很多的方法。

通常情况下，按照上述实现方式，执行复杂任务时可能会调用很多的方法，这在同一个进程中这些方法的开销是可以接受的。但是跨进程或者跨网络调用时，开销会变得很严重。

当客户端为获取多个数据而向服务器发送多次请求，这会严重影响应用的性能。可以发送一次请求到服务器来检索当前需要的所有数据，这样做大大提高了性能，而当前需要的所有数据称之为数据传输对象(DTO)

简介

dto–data transfer object–数据传输对象，字面意思就是一个对象，一个类，这个类包含我们需要的信息（属性）
dto通常用于展现层（Presentation Layer）和应用层（Application Layer）之间相互传递数据。
展现层调用应用层的方法，传递dto参数到应用层，应用层将dto进行必要的处理转化成entity交给领域层执行具体的业务逻辑。
应用层根据展现层需要的数据返回dto给展现层。

优点

1 将领域层抽象

dto提供一种有效的方式将领域对象从展现层抽象化，使展现层和领域层彻底解耦，没有任何相互依赖。
如果彻底修改展现层，仍然可以继续使用已经存在的应用层和领域层。
如果修改了领域层，该变数据库，改变OR/M 框架，这些改动不会对展现层造成太多影响。

2 数据隐藏

dto中字段有很多会和entity中字段一样，为什么不直接用entity呢？因为使用dto更安全更轻量。
a)如何返回entity给展现层，展现层实际上不需要一个完整entity的所有信息，这样做会泄漏entity的信息。
比如只需要一个User的基本信息，但不包含密码和年龄，返回entity会将这些信息泄漏，外层就可以修改，这样就不安全！
2）entity之间会存在一些关联属性，比如一个User有某个Role引用，某个Role有Permission引用。几乎所有的O/RM框架都支持懒加载，返回用户信息极有可能会返回用户、角色、权限这些所有的信息，而这些信息大多是不需要的。

3 序列化问题

展现层将数据返回UI时一般会将dto序列化再返回,
当使用entity时，并且entity中存在一些循环引用，这个时候序列化会失败。

dto设计原则

1.不应该包含任何业务逻辑
2.不应和enity有任何依赖
3.dto作为 输入 时，不应该包含不需要的属性，否则会给开发人员造成困惑。
4.dto作为 输入 时， 不应该在不同的应用服务（ApplicationService）中使用同一个dto，因为不同的应用服务可能需要不同的属性。如果不同的应用服务在输入时使用相同的dto，会造成dto中出现空属性，这会造成应用服务理解起来更复杂，并可能在未来引发一些bug。
5.dto作为输出时并且所有的属性都已赋值，那么可以在不同的应用服务中使用。

以上，仅代表个人总结，
参考文章：
微软官方文档
ABP官方文档