SpringMVC系列之（二） springMVC和Struts异同

布满荆棘的人生 2022-08-10 15:54 171阅读 0赞

Spring MVC属于SpringFrameWork的后续产品，已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。使用 Spring 可插入的 MVC 架构，可以选择是使用内置的 Spring Web 框架还可以是 Struts 这样的 Web 框架。通过策略接口，Spring 框架是高度可配置的，而且包含多种视图技术，例如 JavaServer Pages（[JSP][]）技术、Velocity、Tiles、iText 和[POI][]。Spring MVC 框架并不知道使用的视图，所以不会强迫您只使用 JSP 技术。Spring MVC 分离了[控制器][Link 1]、模型[对象][Link 2]、分派器以及处理程序对象的角色，这种分离让它们更容易进行定制。

#     #

# 下面这些内容表明我学习SpringMVC的思路。 #

![1354171519_5139.png][]

把这张图放在这里，我是想说SpringMVC和Struts2真的是不一样的，虽然在都有着**核心分发器**等相同的功能组件（这些由MVC模式本身决定的）。

# 为什么SpringMVC会赢得最后的胜利呢？谈几点我自己的看法： #

第一、MVC框架的出现是为了将URL从HTTP的世界中映射到JAVA世界中，这是MVC框架的核心功能。而在URL这一点SpringMVC无疑更加优雅。

第二、从设计实现角度来说，我觉得SpringMVC更加清晰。即使我们去对比Struts2的原理图和SpringMVC的类图，它依然很让人困惑，远没有SpringMVC更加直观：

![1354171583_5590.png][]![1354171621_8199.png][]

# SpringMVC设计思路：将整个处理流程规范化，并把每一个处理步骤分派到不同的组件中进行处理。 #

## 这个方案实际上涉及到两个方面：  ##

l 处理流程规范化 —— 将处理流程划分为若干个步骤（任务），并使用一条明确的逻辑主线将所有的步骤串联起来

l 处理流程组件化 —— 将处理流程中的每一个步骤（任务）都定义为接口，并为每个接口赋予不同的实现模式

处理流程规范化是目的，对于处理过程的步骤划分和流程定义则是手段。因而处理流程规范化的首要内容就是考虑一个通用的Servlet响应程序大致应该包含的逻辑步骤：

> l 步骤1—— 对Http请求进行初步处理，查找与之对应的Controller处理类（方法）   ——HandlerMapping
> 
> l 步骤2—— 调用相应的Controller处理类（方法）完成业务逻辑                    ——HandlerAdapter
> 
> l 步骤3—— 对Controller处理类（方法）调用时可能发生的异常进行处理            ——HandlerExceptionResolver
> 
> l 步骤4—— 根据Controller处理类（方法）的调用结果，进行Http响应处理       ——ViewResolver

正是这基于组件、接口的设计，支持了SpringMVC的另一个特性：行为的可扩展性。

## 第三、设计原则更加明朗。 ##

**【Open for extension /closed for modification】**

这条重要的设计原则被写在了Spring官方的reference中SpringMVC章节的起始段：

A key design principle in SpringWeb MVC and in Spring in general is the“Open for extension, closed for modification” principle.

并且重点很好地体现在SpringMVC的实现当中，可以扩展，但却不能改变。我曾经扩展过Spring的IOC、AOP功能，这一点SpringMVC应该和Spring一脉相承。

## 第四、组件化的设计方案和特定的设计原则让SpringMVC形散神聚。 ##

*  **神 —— SpringMVC总是沿着一条固定的逻辑主线运行**
 *  **形 —— SpringMVC却拥有多种不同的行为模式**

SpringMVC是一个基于组件的开发框架，组件的不同实现体系构成了“形”；组件的逻辑串联构成了“神”。因此，“形散神不散”： SpringMVC的逻辑主线始终不变，而行为模式却可以多种多样。

## 第五、更加贴合Web发展的趋势，这个更加虚了，不再展开说这个 问题了。 ##

## 第六、技术上的放缓导致了程序员对Struts2失去了热情，导致SpringMVC依靠自身的努力和Spring的口碑，逐渐显露了自身的优势和特点。 ##

# 为什么SpringMVC会赢得最后的胜利呢？ #

最后，我们不妨想一想Struts2是怎样流行起来的！

我自己是从Struts1用过来的，后来Struts1的问题很明显了，开源社区出现了很多的MVC框架，最为突出的是**Webwork2。**

Webwork2探索了一条与传统Servlet模型不同的解决方案，逐渐被大家熟识和理解，不断发展并得到了广大程序员的认可。它以优秀的设计思想和灵活的实现，吸引了大批的Web层开发人员投入它的 怀抱。

Apache社区与Opensymphony宣布未来的Struts项目将与Webwork2项目合并，并联合推出Struts2。

Struts2能够在一个相当长的时间段内占据开发市场主导地位的重要原因在于其技术上的领先优势。而这一技术上的领先优势，突出表现为对Controller的彻底改造：

public class UserController {
    
        private User user
    
        public String execute() {
    
            // 这里加入业务逻辑代码
    
           return "success";
    
        }
    
    }

从上面的代码中，我们可以看到Webwork2 /Struts2对于Controller最大的改造有两点：

*  在Controller中彻底杜绝引入HttpServletRequest或者HttpServletResponse这样的原生Servlet对象。
 *  将请求参数和响应数据都从响应方法中剥离到了Controller中的属性变量。

这两大改造被看作是框架的神来之笔。因为通过这一改造，整个Controller类彻底与Web容器解耦，可以方便地进行单元测试。而摆脱了Servlet束缚的Controller，也为整个编程模型赋予了全新的定义。从引入新的编程元素的角度来说，Webwork2 / Struts2无疑也是成功的。因为在传统Servlet模式中的禁地Controller中的属性变量被合理利用了起来作为请求处理过程中的数据部分。这样的改造不仅使得表达式引擎能够得到最大限度的发挥，同时使得整个Controller看起来更像是一个POJO。

因而，这种表现形态被笔者冠以的名称 是：POJO实现模式。POJO实现模式是一种具有革命性意义的模式，因为它能够把解耦合这样一个观点发挥到极致。从面向对象的角度来看，POJO模式无疑也是所有程序员所追求的一个目标。这也就是Webwork2 /Struts2那么多年来经久不衰的一个重要原因。

所以，我们看到第一条原因是Struts2依靠技术上的革新赢得了程序员的青睐。但是，这些年来Struts2在技术革新上的作为似乎步子就迈得比较小。我们可以看到，在JDK1.5普及之后，Annotation作为一种新兴的Java语法，逐渐 被大家熟知和应用。这一点上SpringMVC紧跟了时代的潮流，直接用于请求-响应的映射。而Struts2却迟迟无法在单一配置源的问题上形成突破。 当然，这只是技术革新上的一个简单的例子，其他的例子还有很多。

至少给人的感觉是这样的。在这一点上Struts并不是很沾光，因为Spring的口碑和影响力也客观程度上加深了大家对SpirngMVC是技术领导者的印象。

# **区别联系** #

## **1. 实现机制** ##

struts2框架是类级别的拦截，每次来了请求就创建一个controller中对应的Action，然后调用setter getter方法把request中的数据注入 。struts2实际上是通过setter getter方法与request打交道的。struts2中，一个Action对象对应一个request上下文。

spring3 mvc不同，spring3mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去。在spring3mvc中，一个方法对应一个request上下文，而方法同时又跟一个url对应。所以说从架构本身上 spring3 mvc就容易实现restful url。而struts2的架构实现起来要费劲，因为struts2 action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法。

spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的）

spring MVC会稍微比struts快。

## **2. Request数据共享** ##

spring3mvc的方法之间基本上独立的，独享request response数据。请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量。而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的。这不会影响程序运行，却给我们编码、读程序时带来麻烦 。

## **3. 参数传** ##

struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。

## **4. 设计思想上** ##

struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。

## **5. intercepter的实现机制** ##

struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。

spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。

## **6. 另外，spring3 mvc的验证也是一个亮点，支持JSR303** ##

ajax的请求更是方便，只需一个注解@ResponseBody ，然后直接返回响应文本即可。送上一段代码：

@RequestMapping(value="/whitelists")
    public String index(ModelMap map) {
    Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());
    List<Group> groupList = groupManager.findAllGroup(account.getId());
    map.put("account", account);
    map.put("groupList", groupList);
    return "/group/group-index";
    }
    
    // @ResponseBody ajax响应，处理Ajax请求也很方便
    @RequestMapping(value="/whitelist/{whiteListId}/del")
    @ResponseBody
    public String delete(@PathVariable Integer whiteListId) {
    whiteListManager.deleteWhiteList(whiteListId);
    return "success";
    }

接下来实例 [解析springMVC神秘面纱][springMVC]，请期待！

[JSP]: http://baike.baidu.com/view/3387.htm
[POI]: http://baike.baidu.com/view/517279.htm
[Link 1]: http://baike.baidu.com/view/122229.htm
[Link 2]: http://baike.baidu.com/view/2387.htm
[1354171519_5139.png]: https://img-my.csdn.net/uploads/201211/29/1354171519_5139.png
[1354171583_5590.png]: https://img-my.csdn.net/uploads/201211/29/1354171583_5590.png
[1354171621_8199.png]: https://img-my.csdn.net/uploads/201211/29/1354171621_8199.png
[springMVC]: http://blog.csdn.net/lishehe/article/details/38355757