框架的DTO层介绍

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

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

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

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

猜你喜欢

转载自blog.csdn.net/zhaomengsen/article/details/83439430
dto