控制传输服务层

 

简单的说，他是逻辑层与数据层之间的桥梁（或代理）, 它也可以归纳到逻辑层(逻辑层的一部分)，不管理它是属于那一部分，我只是想说明它在整体构架中的重要性和作用，并且它一定存在于逻辑层与数据层之间

逻辑层：我只处理业务需求的逻辑计算，也就是说对原始数据(如；数据库的数据或第三方提供的网络数据或设备上的采集数据)是如何处理的，它不关心这些数据是如何来的，而更关心所提供的数据结构是否能被正确处理

数据层：它可以通过至少一种方式提供从某介质上读或写及相关的功能。(定义：具有提供可用于上层处理的数据供给者都可视为数据层，在某种层面上来说，控制传输服务层也可视为数据层)

一般来说，只要有逻辑层与数据层的存在就一会有“传输层”存在(如数据访问接口)，在业务比较简单的项目中，其功能不是很显著，我们就把它给淡化在逻辑成中，把它给功能化了，而我所说的是要把这个“传输层”给模块化，而且只基于业务规则进行具有可选择性功、功能强大的传输层。

 

 说个比方：

在开发报表的时候，需要把每个分厂的数据合并成一个统一格式的报表

情况：每个分厂的工作内容不同，所提供的格式不同，原始数据的字段名或字段类型也有所差异，并且这些原始数据是分布在不同的区域(设：这些原始数据所在的服务器与我们的服务器是可连接的)

显然，我们不能直接把这些原始数据传递到逻辑层进行报表的计算，需要先获取各服务器上的数据并对其数据进行完整性检查，及数据类型转换及数据的合并，极有可能还要把处理后的数据存储到另的数据库上。

 

这个功能我们可以放在分厂的服务器上处理后再输出，也就是每一个分厂服务器上都要部署这个功能，如果要更新也要统一更新，不能存在不同的版本的功能，这样做风险会很大，但还是要具体情况具体对待。

当然这些事逻辑层去做也没有什么问题，功能仍然可能实现，问题会有很多，1。需要在多线程上做这些事，逻辑层内部是不会涉及线程问题；2。需要多次返回数据层与逻辑层之间；3。破坏了逻辑层的封装，就是说逻辑层与数据层有多个接入点；4。如果是具体细节的开发，远不止这些问题(除非代码结构的控制能力非常好，但后期维护费用将是个大数目)。

那么控制传输服务层如何工作，我做了个简易图：

注：为提高性能，可以把“处理规则接口”部署到另外一台服务器上进行独立处理