Web分层设计研究（四）

控制层设计（二）

 

       我们现在来逐步实现上文我们所构思的设计思路。

       从表现层发送过来的请求包含两个关键数据：1：请求的服务类型，也就是标识。2：请求的表单数据（view object）。其中1是用来辨别所调用的功能模块，2是待处理的数据。在设计控制层的配置文件时，需要考虑3个必要元素：1：控制模块的标识；2：模块对应的类、方法；3：调用该控制模块所需要的参数。

如果不需要把控制深入到类的方法时，在两层通信的协议中需要再定义一个标识用于在类中识别调用的方法。但这就会出现比较严重的标记耦合，因为该标记代表了具体类的方法，而该标记实际上请求的服务类型，也就是标识是代表同一个意义。而且必须在控制模块中编写硬代码进行判断。并不推荐。比较合适的方法是使用IoC（也称DI 依赖注入）进行解藕。IoC有3种实现方式：1：从JNDI等获得被调用者；2：javabean的setter注入；3：构造器注入。使用javabean的setter注入较适合我们利用javabean作为3层之间的传递参数的思想。参考下图：

 

 

实现类对接口的注入使用“通知”模型来实现。当请求数据被发送给控制转发模块时，转发模块根据请求的数据解析并判断需要调用的接口，并在配置中查找接口的实现类。一旦找到，就可以直接调用实现类的对应方法。也就是接口与实现类的映射是在配置容器中完成的，用户只需要了解接口而不需要知道实现类的具体位置和实现方式。为了达到这一点，需要配置容器在初始化时将接口和实现类一并加载到统一的管理容器中，以便在触发接口调用时可以“通知”实现类。同时为了可以将通知事件传递到实现类的具体方法，需要每个实现类都继承一个容器管理的父类。该父类为实现类规定了统一的输入输出口，方法调用的前后都需要经过该父类的方法（类似过滤器）。

在这个实现中，可能存在两个难点：1：当用户调用接口时，如何触发并通知配置容器调用实现类？2：如何才能正确调用实现类的具体方法？第一个问题实际上是如何用javabean的setter注入。如果我们在调用接口的类中声明该接口类，并设置setter方法（这样该类符合javabean的规范），则很容易实现接口与实现类的映射（要明白接口类调用和实现类调用一定在同一个容器中，并且从setter方法注入的是实现类）。第二个问题我们上面已经提示了，如果每个实现类都能受配置容器的管理，就需要为每个实现类定义一个容器管理的父类。该父类大体如下：

 

public class ImplManager

{

　 protected Manager manager;

　 public void registerManager (Manager m_manager) {

　　　　manager = m_manager;

　　}

}

        当我们的实现类继承该类时，registerManager（Manager m_manager)）方法的m_manager参数由容器管理设置，当我们配置接口与实现类的映射后，在容器初始化时就可以把实现类注册到容器中，并为每个实现类分配一个可以由容器访问的Manager（protected域）对象，通过该Manager对象容器就很容易对实现类进行管理。
       控制层的类设计基本上都是围绕着导航配置而产生的。对配置文件解析类的类型需要根据控制层与表现层的所在位置而调整。如果控制层与表现层是容器分离的，则控制层可以是所在web容器的一个基础servlet或过滤器或其他（比如web 服务）。如果是在同一个容器中，控制层往往是注册在表现层配置文件的某个位置，或者是插件形式，或者是代理形式存在。总之需要创建控制层与表现层的联系通道。
      控制层中的接口是对表现层开放的，实现类也是控制层为实现数据转发和服务查找而存在，如果在这层的实现类中编写业务代码，那么将不利于我们对最后一层模型层的设计和解藕。

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