xwork设计原理（其一）

根据xwork框架官方定义：xwork是一个灵活而可靠的基于命令模式的开发框架。

所谓的“命令模式”其本质是请求-响应的模式，就是要实现人机交互的功能。

人机交互的过程是：客户端浏览器发起一个http请求，服务器接到请求之后进行逻辑处理，并将处理结果返回给客户端进行http响应。对于这样的一个过程，我们如何使用Java语言来实现了？

如何从Java语法入手，通过分析对象内部构成机理，我们就会得到三种风格迥异的请求-响应的实现模式。这三种模式，在实际编程中也是不同的web框架实现请求-响应模式的理论基础，下面我们就分析一下三种实现模式。

1、  参数-返回值模式

参数-返回值模式是一种最为直观的请求-响应模式。在这里，我们发现方法在语法上天然的能够与请求-响应模式相对应：

方法签名---请求-响应模式的处理载体

方法参数—请求内容映射

方法返回值—处理结果响应

因此，对象的方法定义与我们之前的请求-响应模式流程是相同的，从而使得对象的方法成为请求-响应模式在Java世界中的一种直观抽象。

我们熟悉的web框架中，springMVC是基于这种模式来定义和实现http请求和处理的。我们通过springMVC的controller代码示例来验证一下：

@Controller

public class UserController{

     @RequestMapping(“/login”)

public ModelAndView login(String username,Stringpassword){

//此处省略业务逻辑处理代码

ModelAndView modelAndView=new ModelAndView(“index”);

return  modelAndView;

}

        在上述代码中，方法的参数（username和password）被视作http请求的概括，它已经被springMVC的框架有效处理并屏蔽了内在的处理细节，呈现出来的是与请求参数名称一一对应的参数列表。而返回值ModelAndView表示http的响应是一个数据与视图的结合体，表示http的处理结果。而函数体（login方法）本身，在其内部包含了进行逻辑处理的整个过程。

        深入研究springMVC框架在Controller的定义中所支持的参数列表和返回值列表，我们可以发现springMVC支持的内容非常宽泛，不仅在参数中支持与参数请求名称一一对应的参数列表，也支持httpServletRequest等web原生对象。事实上，万变不离其宗，无论参数列表如何变化，无论返回值的形式如何变化，参数—返回值这样一种响应模式都是其设计的核心内容。

2、  参数-参数模式

参数—参数模式实际上比参数—返回值模式更早出现，我们所熟知的Servlet标准就是基于参数—参数模式设计的，因此这种参数—参数模式也称之为Servlet模式。

在Servlet标准接口定义中，我们可以看到service方法是http请求处理的实际场所，因而就http请求的响应本身而言，与之前所提到的参数—返回值模式并没有什么本质区别。然而，在service方法以及相关的doGet和doPost方法中，我们可以看到与之前的参数—返回值模式的不同之处。

参数列表----http请求被封装成httpServletRequest对象，而http响应被封装成httpServletResponse对象

返回值-----方法不存在返回值

因此，这里最大的不同就在于将返回值的位置转移到参数列表之中。这种将请求和响应同时至于参数位置的模式，就是我们所说的参数-----参数模式。

从上一部分分析中，我们可以看到参数—返回值模式是对Java语言中的方法这种编程元素的解读。那么为什么Servlet作为Java规范中进行http响应的标准，却采用参数---参数模式实现呢?

Servlet作为一个开发标准，它所设计的接口已经无法再将任何处理职责继续往上层推送了，因为它是我们进行web开发的底层标准。因而对于http请求的处理，在Servlet不仅要知道返回给请求的发起者一个什么样的处理结果，还需要将真实的处理结果呈现在浏览器中。而这一点，不得不借助HttpServletResponse对象的操作在doGet和doPost方法体的内部调用相应的接口函数来完成。因而此时，方法的“返回值”对于Servlet对象来说是没有任何操作上的意义。Servlet对象必须通过HttpservletResponse的调用操作来完成浏览器的响应工作，也就是我们不得不把HttpservletResponse对象置于参数位置的原因。

由此可见，参数---参数模式是一种最为基础的请求---响应实现机制，也是底层规范不得不采用的机制。

3、  POJO模式

如果说参数—返回值模式是请求—响应模式在Java世界中一种直观的抽象，那么POJO模式是一种比较晦涩的请求—响应模式实现方式了，POJO模式与之前介绍的两种实现模式之间巨大的不同在于，POJO模式完全颠覆了前两种实现模式中以Java类中的方法的语法特性作为原型基础进行请求响应的传统模式。在POJO模式中，我们看到虽然实际进行请求的处理和响应的载体依然是POJO中的一个具体方法，但是我们却并没有在这个方法中看到任何参数。所有的请求参数，将以POJO内部属性变量的形式存在并被调用。不仅如此，所有执行结果对象，也同样以POJO内部属性变量的形式存在。这样一来，POJO相对于某一次响应是有状态的响应。这就是POJO模式与前两种模式最大的区别：请求响应的处理类自身是否是一个有状态的对象。我们知道，传统Servlet是有一个无状态的对象，也就是说它不是线程安全的对象，这也成为Servlet对象处理http请求无法逾越的一个障碍。

而POJO模式则直接从概念上突破了Servlet对象的限制，将每一个请求的处理映射到一个线程安全的响应对象中去执行，而从模式上讲，POJO模式是对传统Servlet模式的重大改进，是一种崭新的请求---响应模式实现。

 

分歧和职责

无论哪一种请求响应实现模式，实际上都是站在Java语言的语法角度，将请求—响应的过程进行编程元素抽象化。很显然，三种不同的实现模式在实现上有一定的分歧，他们之前的主要分歧在于：不同的实现模式使用了不同的编程元素（方法参数，方法返回值，类属性）来表达请求---响应模式中不同的逻辑语义。本质原因可以从主观和客户两个方面进行分析：

主观上：不同的实现模式，考虑问题的出发点不同

参数—参数模式和参数—返回值模式，前者作为底层的一个标准，不仅要考虑处理结果的返回，还要考虑后续的程序跳转。而后者了，作为一个非底层实现标准，就不用考虑那么多细节问题了。

客观上：不同的编程元素（方法参数，方法返回值，类属性）所表达的逻辑功能有着天然的差异

我们可以发现，无论分歧发生在那个具体编程元素上，对于响应过程本身而言都是只是“表象”而非“本质”。真正的本质，在于编程元素对于请求—响应过程不同元素职责的理解。

无论哪种实现模式，我们都是在使用编程元素对请求—响应过程进行职责划分。

我们把整个请求-响应过程划分为“请求”和“响应”两个相反的过程，然后分别根据其特点继续将整个过程划分为四个部分：

请求内容：请求的数据

请求处理载体：进行逻辑处理场所

响应内容：逻辑处理的结构数据

响应跳转处理：逻辑处理完后的程序跳转