神马文学网Spring MVC初探
来源：百度文库 编辑：神马文学网 时间：2024/04/28 12:44:13
今天，用一天时间研究了一下Spring MVC，spring-reference1.2.3关于MVC的那章周末的时候差不多看了一遍，并不是很仔细。不过也差不多了解了Spring-MVC是啥子玩意咯。
其实Spring MVC与Tapestry有“异曲同工”之妙。
先说“同工”，Tapestry最本质的特点是什么？我认为页面表现与java逻辑彻底相分离。而spring MVC也是相同的特点，它将页面的java逻辑从页面表现从抽取出来。Tapestry和Spring MVC在这个“分离原则”上，具有相同的理念。。。那么它们的“异曲”又是什么呢？
Tapestry将整个页面表现及逻辑全部纳入其框架，所以，它的页面表现必须要求为html后缀，实际上，虽然我们最开始编辑的是一个单一的几乎绝对纯洁的HTML，但是在运行时，这个纯洁的HTML通过Tapestry被过滤了一遍。过滤的目的是为了给每个组件生成唯一的HTML标签的id以及展现组件功能。由于整个HTML都在Tapestry框架之中，所以对任何组件的操作，都可以在组件对象池里根据唯一的id获取其实例。而每一个涉及到URL的组件都有其对应的service，因此对组件“特定”的URL解析也是“特定”的。
再来看看Spring MVC，它如何将java逻辑与页面表现分离呢？答案在其DispatcherServlet中。Spring MVC通过最传统的在web.xml中过滤url方式，然后在[servlet-name]-servlet.xml配置文件中去匹配。一旦发现匹配的url，就触发配置文件中对应的java类。用配置文件来控制，是Spring一贯的特点。因此，Spring MVC的页面表现，不拘泥于任何文件类型，java，htm，html等等，它所关心的仅仅是URL，甚至可以用链接标签跳转到一个根本不存在页面，比如：http://localhost/test，只要[servlet-name]-servlet.xml中能够匹配到这个URL中的/test，那么就不会报500错误，即进入了Spring MVC框架。至于从java逻辑到页面表现的数据返回，Spring MVC用的是spring.tld标签库。
这种“异曲”造成了Spring MVC和Tapestry完全不同的思维理念，即Spring MVC仍然是面向标签，而Tapestry则面向组件。
呵呵，所以我今天发现一个很有趣的现象。如果在JSP中使用Spring MVC，那么Spring MVC框架会发生作用，而JSP本身也会有JSP的Servlet。我想不出怎样才可以将两种Sevlet进行交互，在Spring官方论坛一定有人提供了解决办法。。。呵呵，不过最后我发现这是个很愚蠢的想法，既然是使用Spring MVC将JSP中java逻辑分离出来，那么又何必在JSP中再用Java？如果要在JSP中用Java，又何必画足添舌用Spring MVC？呵呵。。。
Spring MVC的确是简单易学。周末嘛，玩游戏的时间居多，算下来看spring MVC也就两三个小时，今天算一天，那么从接触到应用，我觉得三天时间差不多能够搞定。在这点上，的确比Tapestry拥有很大的优势。我在javaeye上看见有人说，用Spring MVC（及开发工具）开发项目非常快。我想，如果有工具能够操作[servlet-name]-servlet.xml配置文件的话，的确应该比较快。当然，这还牵扯到开发人员的熟练度。。。另外，我还看不出Spring MVC有任何复用的可能性。而且[servlet-name]-servlet.xml中写入很多配置的话，还是比较混乱。就如同我们现在项目中的applicationContext.xml，当然并不是非常混乱得很难识别，不过还是无法一眼看出各种URL与对应类之间的各种配置关系。
Spring MVC 值得称赞的另外一个优势，就是其单元测试非常容易。因为Spring的页面逻辑类不像Tapestry，Tapestry的java文件全部是抽象类，自然无法作单元测试。
我之所以研究Spring MVC，实际上纯属“路过”。首要目的是为了了解Spring webflow。所以对Spring MVC的研究，差不多到此为止，了解一下即可。。。
其实Spring MVC与Tapestry有“异曲同工”之妙。
先说“同工”，Tapestry最本质的特点是什么？我认为页面表现与java逻辑彻底相分离。而spring MVC也是相同的特点，它将页面的java逻辑从页面表现从抽取出来。Tapestry和Spring MVC在这个“分离原则”上，具有相同的理念。。。那么它们的“异曲”又是什么呢？
Tapestry将整个页面表现及逻辑全部纳入其框架，所以，它的页面表现必须要求为html后缀，实际上，虽然我们最开始编辑的是一个单一的几乎绝对纯洁的HTML，但是在运行时，这个纯洁的HTML通过Tapestry被过滤了一遍。过滤的目的是为了给每个组件生成唯一的HTML标签的id以及展现组件功能。由于整个HTML都在Tapestry框架之中，所以对任何组件的操作，都可以在组件对象池里根据唯一的id获取其实例。而每一个涉及到URL的组件都有其对应的service，因此对组件“特定”的URL解析也是“特定”的。
再来看看Spring MVC，它如何将java逻辑与页面表现分离呢？答案在其DispatcherServlet中。Spring MVC通过最传统的在web.xml中过滤url方式，然后在[servlet-name]-servlet.xml配置文件中去匹配。一旦发现匹配的url，就触发配置文件中对应的java类。用配置文件来控制，是Spring一贯的特点。因此，Spring MVC的页面表现，不拘泥于任何文件类型，java，htm，html等等，它所关心的仅仅是URL，甚至可以用链接标签跳转到一个根本不存在页面，比如：http://localhost/test，只要[servlet-name]-servlet.xml中能够匹配到这个URL中的/test，那么就不会报500错误，即进入了Spring MVC框架。至于从java逻辑到页面表现的数据返回，Spring MVC用的是spring.tld标签库。
这种“异曲”造成了Spring MVC和Tapestry完全不同的思维理念，即Spring MVC仍然是面向标签，而Tapestry则面向组件。
呵呵，所以我今天发现一个很有趣的现象。如果在JSP中使用Spring MVC，那么Spring MVC框架会发生作用，而JSP本身也会有JSP的Servlet。我想不出怎样才可以将两种Sevlet进行交互，在Spring官方论坛一定有人提供了解决办法。。。呵呵，不过最后我发现这是个很愚蠢的想法，既然是使用Spring MVC将JSP中java逻辑分离出来，那么又何必在JSP中再用Java？如果要在JSP中用Java，又何必画足添舌用Spring MVC？呵呵。。。
Spring MVC的确是简单易学。周末嘛，玩游戏的时间居多，算下来看spring MVC也就两三个小时，今天算一天，那么从接触到应用，我觉得三天时间差不多能够搞定。在这点上，的确比Tapestry拥有很大的优势。我在javaeye上看见有人说，用Spring MVC（及开发工具）开发项目非常快。我想，如果有工具能够操作[servlet-name]-servlet.xml配置文件的话，的确应该比较快。当然，这还牵扯到开发人员的熟练度。。。另外，我还看不出Spring MVC有任何复用的可能性。而且[servlet-name]-servlet.xml中写入很多配置的话，还是比较混乱。就如同我们现在项目中的applicationContext.xml，当然并不是非常混乱得很难识别，不过还是无法一眼看出各种URL与对应类之间的各种配置关系。
Spring MVC 值得称赞的另外一个优势，就是其单元测试非常容易。因为Spring的页面逻辑类不像Tapestry，Tapestry的java文件全部是抽象类，自然无法作单元测试。
我之所以研究Spring MVC，实际上纯属“路过”。首要目的是为了了解Spring webflow。所以对Spring MVC的研究，差不多到此为止，了解一下即可。。。
Spring MVC初探
SPRING MVC
Spring MVC 入门+MVC 简介
Spring MVC 入门
Spring mvc控制器
Spring mvc控制器2
Spring MVC 入门
Spring MVC 入门+MVC 简介test
Spring MVC 入门+MVC 简介1
开发Spring MVC应用程序(2)
Home - Spring Portlet MVC - Confluence
开发Spring MVC应用程序(1)
Spring MVC step-by-stepd
Spring MVC step-by-step
Spring MVC step-by-step1
Struts VS Spring两种MVC框架
Struts VS Spring 两种MVC框架
Spring学习日记 - 在spring mvc中集成tiles
Spring 系列，第 3 部分: 进入 Spring MVC
1.2 Spring初探 - 《Spring 2.0宝典》
1.2 Spring初探 - 《Spring 2.0宝典》
在spring mvc框架中显示xml视图
Struts VS Spring 两种MVC框架比较
用 Spring MVC 来处理向导式复杂表单