SpringMVC前传--从Struts 1.x-2.x MVC-Spring 3.0 MVC

http://downpour.iteye.com/blog/1330537

在我们熟知的建立在三层结构（表示层、业务逻辑层、持久层）基础之上的J2EE应用程序开发之中，表示层的解决方案最多。因为在表示层自身的知识触角很多，需要解决的问题也不少，这也就难免造成与之对应的解决方案层出不穷。

笔者在很多讨论中经常可以看到类似“某某框架已死”，或者“某某框架已经足以打败所有其他的框架”的言论。事实上，每一种解决方案都有着自身独有的存在价值和历史背景。如果单单从某一个方面或者某几个方面去看一个框架，那么评论难免有失偏颇。

所以，整个系列的第一篇文章，我们脱开SpringMVC框架本身，把SpringMVC放到一个更大的知识体系范围之中，讲一讲整个Web开发领域、尤其是MVC框架的发展历程。正如“认识历史才能看清未来”，当我们能够正确审视整个MVC框架的发展历程，也就能够分析它的发展趋势，并且站在一个更高的高度来对所有的解决方案进行评价。

两种模型

从整个B/S程序的运行结构来看，J2EE的表示层解决方案实际上是对“请求-响应”模式的一种实现。既然谓之“请求-响应”也就势必存在着两大沟通角色：

由于这两大角色的承载载体和编程语言实现基础都不同，因而也就产生了两种截然不同的针对表示层的解决方案的设计思路：

以服务器端应用程序为主导来进行框架设计
以浏览器页面组件（及其自身的事件触发模型）为主导来进行框架设计

业界对于上述这两种不同的设计模型也赋予了不同的名词定义：前一种被称之为MVC模型；后一种则被称之为组件模型，也有称之为事件模型。

注：笔者个人对于这两种模型的概念定义并不是非常认同。因为在笔者个人的观点认为，MVC模型的定义角度所针对的是编程元素的划分；而组件模型（事件模型）的定义角度是动态交互方式的表述。所以我们在这里强调的是解决方案自身所设立的基准和侧重点的不同。

从使用者的社区力量上来看，无疑MVC模型获得了更多程序员的青睐。这里面的原因很多，我们在这里也不想过多展开对两种不同编程模型之间的讨论。不过在这里，我们将针对同一个业务场景（用户注册）分别给出基于这两个编程模型的代码示例，帮助读者了解这两种编程模型在设计思想上的不同之处。