Java DTO(DataTransferObject)

分布式系统（distributed system）：是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由通信网络互联的多处理机体系结构上执行任务的系统。它包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。


(以下资料没整理)

层间数据传输的过程就是服务的执行者将数据返回给服务的调用者的过程。

层间数据传输假定的场景是“服务器将执行的数据结果如何传递给远程客户端”

在分布式系统中，客户端和服务器端交互有两种情形：第一个是客户端从服务器端读取数据；第二个是客户端将本身的数据传递给服务器端。

DTO(Data Transfer Object，数据传送对象)是解决这个问题的比较好的方式。DTO是一个普通的Java类，它封装了要传送的批量的数据。当客户端需要读取服务器端的数据的时候，服务器端将数据封装在DTO中，这样客户端就可以在一个网络调用中获得它需要的所有数据。

使用DTO的时候，一个主要问题是选择什么样的DTO：这个DTO能够容纳哪些数据，DTO的结构是什么，这个DTO是如何产生的。

DTO是服务器端和客户端进行通信的一个协议格式，合理的DTO设计将会使得服务器和客户端的通信更加顺畅。

域模型是指从业务模型中抽取出来的对象模型，比如商品、仓库。在J2EE中，最常见的域模型就是可持久化对象，比如Hibernate中的PO、EJB中的实体Bean。

在分布式系统中，域模型完全位于服务器端。根据持久化对象可否直接传递到客户端，域对象可以分为两种类型：一种是服务器端的持久化对象不可以直接传递到客户端，比如EJB中的实体Bean是不能被传递到客户端的；一种是持久化对象可以直接传递到客户端，比如Hibernate中的PO变为 detached object以后就可以传递到客户端。


使用域DTO会有如下好处：

域模型结构可以在一次网络调用中复制到客户端，客户端可以读取、更新这个DTO而不需要额外的网络调用开销，而且客户端还可以通过将更新后的DTO回传到服务器端以更新数据

易于实现快速开发。通过使用域DTO可以直接将域模型在层间传输，减少了工作量，可以快速地构建出一个应用。

但它也有如下的缺点：

将客户端和服务器端域对象耦合在一起。如果域模型变了，那么相应的DTO也会改变，即使对于Hibernate这种PO、DTO一体的系统来说也会同样导致客户端的代码要重新编译或者修改。

l 不能很好地满足客户端的要求。客户端可能只需要域对象的20个属性中的一两个，采用域DTO则会将20个属性都传递到客户端，浪费了网络资源。

l更新域对象很烦琐。客户端对DTO可能做了很多更新或者很深层次的更新，要探查这些更新然后更新域对象是很麻烦的事情。

域DTO解决了在客户端和服务器端之间传递大量数据的问题，但是客户端往往需要更细粒度的数据访问。

可定制的DTO，使它仅封装客户端需要的数据的任意组合，完全与服务器端的域模型相分离。定制DTO与域DTO的区别就是它不映射到任何服务器端的域模型。

定制DTO主要用于只读操作，也就是DTO只能用来显示，而不能接受改变。既然定制DTO对象仅仅是一个数据的集合，和任何服务端对象没有必然的关系，那么对定制DTO进行更新就是没有意义的了。

定制DTO的缺点如下：

l   需要创建大量的DTO。使用定制DTO会爆炸式地产生大量的对象。

l   客户端DTO的版本必须和服务器端的版本一致。由于客户端和服务器端都通过定制DTO通信，所以一旦服务器端的DTO增加了字段，那么客户端的代码也必须重新编译，否则会产生类版本不一致的问题。


数据访问模式：

如果说数据访问技术是一些得心应手的兵器的话，数据访问模式就应该是各种武功秘笈了，它们才是致胜的法宝。 架构师在不同的应用场合下可能会选择不同的数据访问模式，并且还会不断地推陈出新，这里不会也不可能穷尽所有的数据访问模式，而只是列举了其中最为典型的几个。

在线访问


Data Access Object（DAO）


一个典型的 DAO 实现通常有以下组件：

一个 DAO 工厂类

一个 DAO 接口

一个实现了 DAO 接口的具体类 数据传输对象(有时称为值对象) 这当中具体的 DAO 类包含访问特定数据源的数据的逻辑。

DTO模式


Data Transfer Object 是经典 EJB 设计模式之一。 DTO 本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其它的对象行为。

1．使用编程语言内置的集合对象，它通常只需要一个类，就可以在整个应用程序中满足任何数据传输目的；而且因为几乎所有的编程语言都内置了集合类型，我们不需要再另外编写这个类的实现代码。同时，使用内置的集合对象来实现 DTO 对象的时候，客户端必须按位置序号（在简单数组的情况下）或元素名称（在键控集合的情况下）访问集合内的字段。此外，集合存储的是同一类型（通常是最基本的 Object 类型）的对象，这有时会导致在编译时碰到一些无法检测到编码错误，这是采用内置集合对象来实现 DTO 对象的缺点。


2．通过创建自定义类来实现 DTO 对象，通过定义显式的 get 或是 set 方法来访问数据。这种方式的主要优点在于能够提供与任何其他对象完全一样的、客户端应用程序可访问的强类型对象，这种对象可以提供编译时的类型检查；但是主要缺点在于增加了编码的工作量，因为如果应用程序发出许多远程调用的话，我们需要自己编写大量的调用代码。


具体实现中有许多方法试图将上述这两种方法的优点结合在一起。第一种方法是代码生成技术，该技术可以生成脱离现有元数据（如可扩展标记语言 ( XML ) 架构）的自定义 DTO 类的源代码；第二种方法是提供更强大的集合，尽管它也是平台内置的一般的集合，但它将关系和数据类型信息与原始数据存储在一起，比如 IBM 提出的 SDO 技术或是微软 ADO.NET 中的 DataSet 就支持这类方法。


无论采用上述的哪种方法，当有了 DTO 对象之后，就需要用数据来填充它。在大多数情况下，DTO 内部填充的数据往往来自于多个其它种类的对象；由于 DTO 对象中很少有具体的数据操作方法，因此它很难从其它对象中直接提取数据。这种设计是有道理的，因为如果不让 DTO 对象知道如何调用其它对象的方法，我们就可以在不同的场合直接重用 DTO 对象，这样一旦其它对象发生更改，我们无需修改 DTO 对象的设计。