框架的DTO层介绍

 新年哪里也没有去，呆在家里写了几篇Blog与大家交流一下。平时工作很忙，也难得有时间写点东西。大年三十、初一各发了一往篇，还有那么多的博友陪我一起，像我一样，呵呵。

上面粗粗的介绍了ORM层、业务层。ORM主要是在数据访问，把程序从千篇一率的存储过程调用，从容易出错的Sql语句中解脱出来；业务层主要是规范业务逻辑的组织，简化事务处理，把精力用到处理业务逻辑的刀刃上。对于很小的BS软件，有这两层已经算是可以用了，但如果要考虑到集成、客户端，就会感觉只有这些还是远远不够的，数据处理的灵活性还不够，客户端界面的展示与业务逻辑层耦合的太紧密。

下面就要介绍到数据交换层、服务层、DTO层。我先从DTO层介绍吧，对于DTO层，有的朋友可能会感觉没有存在的必要，多了一层，也或许是这样。复杂度，工作量，对人的要求也高了，成本也高了，等等，都是要考虑的方面。

DTO层，也就是在服务器端和客户端进行沟通的，把业务逻辑层的数据传输到客户端，再把客户端的数据传输到服务器端，既然这样，那么在DTO与逻辑层数据Data之间就存在一个数据交换，数据交换在后面再介绍。DTO的数据要能够支持客户端的数据绑定，可能有的朋友会问，用业务层的数据不可以吗？答案是：如果是在局域网内可以，在广域网上不可以。业务层的数据存在很多数据是延迟加载过来的，在网络上传输数据通常是要求一次把比较多的数据传输过去，也就是通常的粗粒度设计，建立连接等开销太大、时延太大了。另外，客户端需要哪些数据，需要传输哪些数据，业务逻辑层不清楚，业务层只知道我能够提供哪些数据，DTO是知道我需要哪数据，两者所站的角度不同。业务逻辑层的数据相当于数据的提供者，DTO是数据的消费者。朋友们，再发挥一下想像，是不是可以这么理解，因为这个的存在，业务逻辑层设计的时候，可以不考虑界面是如何显示的，只要关心我的业务逻辑就可以，只要我能够提供这些数据就可以了，你是从一个对象里面得到的，还是从几个关联对象里面找到的，还是从别的系统里通过WebService得到的，业务逻辑层不关心，关心的是业务逻辑层可以提供这么多数据就够了，对于客户端，只关心有这么数据我可以处理，你是从哪里得到，客户端不关心，只关心我有这么多的数据可以处理。这样，就可以实现客户端与服务器端分离开发，设计的时候更重要的是针对中间的服务和要处理的数据设计，或许就是面向契约和服务设计吧。

借用SDO的一张图。

看了这张图，我估计很多人是非常熟悉的，如果从上面的观点和角度去考虑DTO的问题，那么这张图是自然而然的事情了，或许也是框架升级的一个必然趋势吧。这张图我是在2007年的9月份才看到的，但是时候完整的框架已经开始使用了，思想应该是相似的。

不过，这个DTO/SDO当时真的害的我很辛苦。

DTO要能够支持：数据绑定、历史记录、级联触发、合并集合、序列化与反序列化，要实现一个大的递归，从其中的任何一个对象开始，能够找出整个传递的