数据描述传输机制

 

在动态的WEB应用中，数据传输一般都是这样的：

页面(表单)-request解析-业务执行-结果返回request/response-页面展现

在分层应用中，提到了DTO的概念，于是数据传输变成了这样：

页面(表单)-request解析-DTO 业务执行-结果返回request/response-DTO-页面展现

在structs等框架中的FormBean作用和DTO差不多

在面向对象的分析与设计中，操作的是对象，但业务操作中的数据库仍多为关系数据库，与是出现了O/R Mapping工具，如Hibernate。于是数据传变成了这样：

页面(表单)-request解析-DTO-PO-业务执行-PO-结果返回request/response-DTO-页面展现

因为很多时候PO与DTO的结构及作用是一样的，常常会混在一起使用：

页面(表单)-request解析-PO- 业务执行-PO-结果返回request/response-PO-页面展现

当PO放弃了相关的方法，只存在数据时，也就是变成了只是一个数据的集合，只是传输数据的工具。因此，若无好的工具支持管理，并不支持对一些为框架而O/R Mapping，产生一堆只有get和set方法的类和配置文件的做法。

 

当PO沦为和DTO一样时，为什么还要选择这样的机制来传输呢？

这是因为它们都是对象，除了传输数据，还可以带有数据类型，甚至是一些业务逻辑含义描述。只是在同一系统里，开发时页面展现，业务逻辑，数据操作都是可以统一设计开发的，所以也就一直用着PO/DTO之类的传输机制。

 

但是如果页面展现，业务逻辑，数据操作分开，或者业务服务类之间要相互调用，或者系统之间要数据传输，采用PO/DTO之类的传输机制，将纯数据变成有数据相关的含义的BEAN，在各层或各服务各系统就要进行侵入，从而有大高的耦合性，依赖太强了。目前在银行很多系统间的传输数据很多时候还是用字符串，双方约定好传输定义从面进行数据传输。

 

数据和在数据之上的含义既可以统一在一起又可以分开，试想通讯协议各层都有一个报文头和报文体，它们和数据传输是同样的道理。这就是所设想的数据描述的传输机制。

如果将数据描述和数据一起传输，接收数据者就可以按发送者数据描述的要求应用数据了。如果数据描述部分设置在发送者和接收者两端，就象一个协议，双方就可以自由传输数据了。有了数据描述的独立，双方之间就不会再有相互侵入，大大降低了耦合性，提高了灵活性。