中国网路原创音乐DTO团队；成立于2013年3月9日，汇聚全国各地众多音乐爱好者加入，团队共二十一人，团长俊懿，在词曲、编曲、演唱、混音方面取得了优异的成绩。代表作品有《残破》、《邪恶吉他》《Darry Ring》《独伤》等。

团长：俊懿

副团：汐雪、薛凌

词曲部：阿浩、青云、火昱、黄柯、易爵

编曲部：龙欢

歌手部：许磊、呆呆、清瑶

外交部：莫希

接待部：婉儿

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

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

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

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

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

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

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

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

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

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

MartinFowler在Patterns of Enterprise Application Architecture [Fowler03] 中对此模式进行了说明。

下图显示客户端应用程式如何进行一系列远程调用以检索客户名称的各个元素。

DTO 允许远程对象在单个远程调用中将整个客户名称返回给客户端。在此示例中，这样做将使调用次数从 4 次减为 1 次。客户端进行单个调用，然后在本地与 DTO 互动，而不用进行多次远程调用（见图 2）。

DTO 是一组需要跨进程或网路边界传输的聚合数据的简单容器。它不应该包含业务逻辑，并将其行为限制为诸如内部一致性检查和基本验证之类的活动。注意，不要因实现这些方法而导致 DTO 依赖于任何新类。

在设计数据传输对象时，您有两种主要选择：使用一般集合；或使用显式的 getter 和 setter 方法创建自定义对象。

一般集合的优点是，只需要一个类，就可以在整个应用程式中满足任何数据传输目的。此外，集合类（例如，简单数组或散列图）内置于几乎所有语言库中，因此您根本不必编写新类的代码。对 DTO 使用集合对象的主要缺点是，客户端必须按位置序号（在简单数组的情况下）或元素名称（在键控集合的情况下）访问集合内的栏位。此外，集合存储的是同一类型（通常是最一般的 Object 类型）的项目，这可以导致在编译时无法检测到的微妙但致命的编码错误。

如果为每个 DTO 创建自定义类，则可以提供与任何其他对象完全一样的、客户端应用程式可访问的强类型对象，这样的对象可以提供编译时检查，并支持代码编辑器功能（如 Microsoft® IntelliSense® 技术）。主要缺点是，如果应用程式发出许多远程调用，则您最终可能必须编写大量类的代码。

许多方法试图将这两种方法的优点结合在一起。第一种方法是代码生成技术，该技术可以生成脱离现有元数据（如可扩展标记语言 (XML) 架构）的自定义 DTO 类的原始码。第二种方法是提供更强大的集合，儘管它是一般的集合，但它将关係和数据类型信息与原始数据存储在一起。Microsoft DataSet 支持这两种方法

有了 DTO 类以后，需要用数据填充它。大多数情况下，DTO 内的数据来自多个域对象。因为 DTO 没有行为，因此它不能从域对象提取数据。这是对的，因为如果让 DTO 不知道域对象，您就可以在不同的上下文中重用 DTO。同样，您不希望域对象知道 DTO，因为这可能意味着更改 DTO 将要求更改域逻辑中的代码，这将导致大量维护任务。

最佳的解决方案是使用 Assembler 模式 [Fowler03]，该模式可以用业务对象创建 DTO 或者相反。Assembler 是 Mapper 模式的专门实例，在 Patterns of Enterprise Application Architecture [Fowler03] 中也提到过它。

Assembler 的关键特徵是 DTO 和域对象不相互依赖。这就消除了这两种对象的相互影响。不利方面是 Assembler 同时依赖于 DTO 和域对象。对这些类的任何更改都可能导致必须更改 Assembler 类。