Web分层设计研究（三）

控制层设计（一）

 转自：http://blog.csdn.net/lemonfamily/article/details/1686477

        控制层通常为请求/响应数据进行导航而存在。同时它具有一定的数据处理功能，但处理的目的应出于组装符合合上下文调用规约的目的，不应该包含有业务逻辑。在与表现层通信时，控制层负责响应表现层的请求，并把模型层返回的消息或处理的结果转换为表现层的可以识别的显示逻辑。在与模型层通信时，控制层负责将表现层的请求通过服务查找功能调用系统的业务逻辑处理模块并接收返回的消息。

       控制层与表现层存在这一定的耦合性，因为它可能需要和表现层共享web容器的缓存机制。比如servlet的request或session等，在某些情况下，控制层需要把数据转换成可以被“展现”的数据格式才能把数据传递给表现层。如我们前面讨论的有关表现层设计的一样，处理显示逻辑回显到客户端时，对于不同的表达需求这两层需要进行一定协调。

       内聚和耦合是与类和服务相关联的概念。高内聚应该是功能的内聚，低耦合应该是数据的耦合。在设计分层时，我们主要的目标是，使用可复用构件完成编码并保证编码风格的统一，各个层次的功能独立，分工明晰。因此需要实现：显示内容和显示逻辑分离，显示数据处理和业务逻辑分离，业务逻辑和数据调用分离。

       下面是一个简单的控制层实现：

 

 

 

        在一般的web转发配置的设计中，都将表现层的页面转向与控制层的转发配置聚合在一起。以解决表现层的请求与控制层的控制模块映射问题。理想的情况是，不同层次应该使用不同的配置，这是出于设计中低藕合的意图，为达到这个目的，并避免把标记和表单数据混杂在一起，这里提供一种使用标记识别和缓存机制的设计思路：

 

       这种方案最多需要经过两次通信匹配到对应的控制器：首先表现层处理来自客户端的请求，生成一个标识，并把处理后的表单数据缓冲到内存中，然后发送标识给控制层，控制层接收该标识到配置文件中查找匹配的项，通过该项中的需求参数判断是否需要去取数据，如果需要，则和表现层的标记处理模块通信并获取数据返回给控制层的标记处理模块，最后通过标记处理模块将数据和控制权（通过IoC）的请求导航到配置文件匹配项对应的控制器。

       可能有人怀疑这种方案在并发多线程环境中实现的可能性，这里有两种方法可以让标识和数据被正确的传递。一种是使用用户身份标记（ID）附加到传递的标识中，并在接收端缓存该id。另一种是使用线程局部变量（ThreadLocal）保证标识的私有性。第2种方案适合两层在同一个容器中的情况。

       当然这样的做法是否有必要，应该根据具体应用的环境而定。

    下面我们来讨论控制器：

       控制层的导航配置文件，负责解析来自表现层和自身的服务标记，并通过匹配服务标记查找对应的目标。通常把表现层与控制层的通信的javabean对象称为view object，而控制层与上层的通信的javabean 对象称为 business object，为了进行区分，这两个javabean一般不能指向同一个对象（类）。合理的设计是，vo包含页面显示逻辑所需要的元素，在通过控制层时，vo中的元素被“加工”处理，转化为包含业务逻辑处理所需元素的bo对象，bo元素（变量）不一定被全部填充，但里面的元素需要完整，以保持与上层协议的一致性，也就是使用同一个媒介（javabean）进行通信。

       不同的请求可能会对应到不同的控制器，限制控制器的作用域有助于实现功能的内聚。一个控制器一般只接收一种view object，并产出一个business object。如果只是如此简单，那么我们完全可以使用抽象---具体的继承方式为控制器规定统一的处理方式和统一的输入输出。但有时控制器往往代表一个功能模块，而这个功能模块可能包含几个独立的子功能。比如一个表单操作中的CRUD可以只经过同一个控制器，不可能有相同的处理和一致的输入输出。这时转发配置需要能识别并正确调用控制器的具体子功能。控制的层次深入到了类中的方法。解决的办法就是使用类自省和反射机制。这已经涉及了目前比较流行的AOP编程的知识，有兴趣的去网上搜索，相信都可以找到一个比较合适的方法。