框架的DTO层介绍

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

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

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

DTO层，也就是在服务器端和客户端进行沟通的，把业务逻辑层的数据传输到客户端，再把客户端的数据传输到服务器端，既然这样，那么在DTO与逻辑层数据Data之间就存在一个数据交换，数据交换在后面再介绍。DTO的数据要能够支持客户端的数据绑定，可能有的朋友会问，用业务层的数据不可以吗？答案是：如果是在局域网内可以，在广域网上不可以。业务层的数据存在很多数据是延迟加载过来的，在网络上传输数据通常是要求一次把比较多的数据传输过去，也就是通常的粗粒度设计，建立连接等开销太大、时延太大了。另外，客户