DTO

简介　　数据传输对象（DTO），是一种设计模式之间传输数据的软件应用系统。数据传输目标往往是结合使用的 数据访问对象从数据库中检索数据。

　　数据传输对象与数据交互对象或数据访问对象之间的差异是一个以不具有任何行为除了 存储和检索的数据（访问和存取器）。

　　在传统的系统（企业JavaBeans）体系结构，数据传输目标服务的双重目的：第一，他们围绕这个问题，pre-ejb实体不是序列化的；其次，他们含蓄地定义一个组装阶段，所有要使用的数据的提取和整理到数据传输目标之前返回控制[表现层]；第三个原因是使用数据传输目标可能是某些应用层不应该能够访问底层的数据访问对象，从而改变数据。

编辑本段产生

　　Data Transfer Object（数据传输对象）

　　您正在设计一个 分布式应用程序，为了满足单个 客户端请求，您发现自己对一个远程接口发出了多个调用，而这些调用所增加的响应时间超出了可接受的程度。

编辑本段影响因素

远程调用

　　在与远程对象通信时，请考虑下列需要权衡的因素：

　　远程调用（那些必须跨越网络的调用）速度缓慢。虽然许多远程调用 框架可以隐藏进行远程调用的复杂性，但是它们不能消除发生通信所需的步骤。例如，必须先找到远程对象位置，而且建立与远程计算机的连接，然后才能将数据串行化为 字节流，然后可能进行加密，最后才能将其传输到远程计算机。

网络性能

　　在考虑网络性能时，必须同时考虑滞后时间和 吞吐量。简单地说，"滞后时间"描述了数据的首字节到达目的地之前所经过的时间。"吞吐量"描述了在某个时间段（例如 1 秒）内通过网络发送的数据字节数。在基于 IP路由的现代网络（例如 Internet）中，滞后时间可以是比吞吐量更大的因素。这意味着，传输 10 字节数据所用的时间可能几乎等于传输 1,000 字节数据所用的时间。在使用 无连接协议（如 HTTP）时，此效果尤其明显。通常， 网络速度越快可以使吞吐量得以增加，但是，要减少滞后时间则会更加困难。

接口设计

　　在设计对象接口时，好的做法是将大量 信息隐藏在对象内，并提供一组细粒度方法来访问和操作该信息。"细粒度"意味着每个方法都应该负责单个的、相当小的和基本的功能单位。此方法简化了编程，并提供了对对象内部的更佳抽象，从而增加了重用的可能性。必须根据以下事实对此进行平衡取舍：使用较细粒度的方法意味着需要调用更多的方法才能执行高级别的任务。通常，在同一进程内调用方法时，这些额外 函数调用的开销是可接受的；但是，在跨进程和 网络边界调用这些方法时，开销可能变得难以接受。

　　避免远程调用中固有的滞后时间问题的最佳方法是进行更少的调用，并让每个调用传递更多的数据。做到这一点的一种方法是，使用长 参数列表来声明远程方法。这样， 客户端就可以在单个调用中将更多的信息传递给远程组件。但是，这样做会使针对此接口的编程容易出错，因为程序很可能仅按调用语句中的位置来调用外部方法的参数。例如，如果远程方法接受 10 个字符串参数，则开发人员很容易按错误顺序传递参数。 编译器将无法检测到这样的错误。

　　长参数列表无助于从远程调用向客户端返回更多的信息，因为大多数的编程语言将方法调用的返回类型限制为单个参数。而巧合的是，在传输大多数数据时通常需要返回较多信息。例如，许多用户接口传输少量的信息，却希望返回大量结果数据。

 

 

简介　　数据传输对象（DTO），是一种设计模式之间传输数据的软件应用系统。数据传输目标往往是结合使用的数据访问对象从数据库中检索数据。

　　数据传输对象与数据交互对象或数据访问对象之间的差异是一个以不具有任何行为除了存储和检索的数据（访问和存取器）。

　　在传统的系统（企业JavaBeans）体系结构，数据传输目标服务的双重目的：第一，他们围绕这个问题，pre-ejb实体不是序列化的；其次，他们含蓄地定义一个组装阶段，所有要使用的数据的提取和整理到数据传输目标之前返回控制[表现层]；第三个原因是使用数据传输目标可能是某些应用层不应该能够访问底层的数据访问对象，从而改变数据。

优点

　　减少了远程调用次数。通过在单个远程调用中传输更多的数据， 应用程序可以减少远程调用次数。

　　提高了性能。远程调用可以使应用程序的运行速度大大降低。减少调用次数是提高性能的最佳方法之一。在大多数方案中，传输大量数据的远程调用所用的时间与仅传输少量数据的调用所用的时间几乎相等。

　　隐藏内部情况。在单个调用中来回传递更多的数据，还可以更有效地将远程应用程序的内部情况隐藏在粗粒度接口的背后。这就是使用 Remote Facade 模式 [Fowler03] 的主要原因。

　　发现 业务对象。在一些情况下，定义 DTO 有助于发现有意义的业务对象。在创建用作 DTO 的自定义类时，您通常会注意到作为一组 凝聚性信息而显示给用户或另一个系统的元素分组。通常，这些分组用作描述应用程序所处理的业务域的对象的有用原型。

　　可测试性。将所有参数封装到可序列化对象中可以提高 可测试性。例如，可以从 XML 文件中读取 DTO，并调用远程函数以测试它们。同样，可以轻松地将结果再序列化为 XML 格式，并将 XML 文档与所需结果进行比较，而不必创建冗长的比较 脚本。

缺点

　　可能需要太多的类。如果选择了使用强类型的 DTO，则可能必须为每个远程方法创建一个（如果考虑返回值，则为两个）DTO。即使在粗粒度接口中，这也可能导致大量的类。编写如此数量的类的代码并管理这些类会是很困难的。使用自动 代码生成可以在一定程度上缓解此问题。

　　增加计算量。如果将服务器上的一种数据格式转换为可以跨 网络传输的 字节流，并在 客户端 应用程序内转换回对象格式，可以带来相当大的开销。通常，需要将来自多个源的数据聚合到服务器上的单个 DTO 中。要提高通过网络进行远程调用的效率，必须在任一端执行其他计算，才能聚合和 串行化信息。

　　增加编码工作量。可以用一行代码完成将 参数传递到方法的操作。使用 DTO 要求实例化新对象，并为每个参数调用 setters 和 getters。编写此代码可能是很乏味的。