SpringMVC与Struts2的对比.doc

下面这些东西基本都是我从网上粘贴过来的，没有那么多耐心和时间一个字一个字的敲了，但是基本能表明我选择SpringMVC的思路和原因。 把这张图放在这里，我是想说SpringMVC和Struts2真的是不一样的，虽然在都有着核心分发器等相同的功能组件（这些由MVC模式本身决定的）。 ? 为什么SpringMVC会赢得最后的胜利呢？谈几点我自己的看法： ? 第一、MVC框架的出现是为了将URL从HTTP的世界中映射到Java世界中，这是MVC框架的核心功能。而在URL这一点SpringMVC无疑更加优雅。 ? 第二、从设计实现角度来说，我觉得SpringMVC更加清晰。即使我们去对比Struts2的原理图和SpringMVC的类图，它依然很让人困惑，远没有SpringMVC更加直观： ? ???????????? 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