来自: http://blog.csdn.net//chenleixing/article/details/43410713 ?? 目录 四、spring mvc DispatcherServlet说明 五、spring mvc 父子上下文的说明 六、springMVC-mvc.xml 配置文件片段讲解 八、spring mvc 请求如何映射到具体的Action中的方法 九、 spring mvc 中的拦截器: 十一、 spring mvc 如何实现全局的异常处理 十二、 spring mvc 如何把全局异常记录到日志中 十三、 如何给spring3 MVC中的Action做JUnit单元测试 十四、 spring mvc 转发与重定向 (带参数重定向) 十五、 spring mvc 处理ajax请求 十六、 spring mvc 关于写几个配置文件的说明 十七、 spring mvc 如何取得Spring管理的bean 十八、 spring mvc 多视图控制器 十九、
说明:本作者是文章的原创作者,转载请注明出处:本文地址:http://elf8848.iteye.com/blog/875830
一、前言: 为开发团队选择一款优秀的MVC框架是件难事儿,在众多可行的方案中决择需要很高的经验和水平。你的一个决定会影响团队未来的几年。要考虑方面太多: 1、简单易用,以提高开发效率。使小部分的精力在框架上,大部分的精力放在业务上。 2、性能优秀,这是一个最能吸引眼球的话题。 3、尽量使用大众的框架(避免使用小众的、私有的框架),新招聘来的开发人员有一些这方面技术积累,减低人员流动再适应的影响。
如果你还在为这件事件发愁,本文最适合你了。选择Spring MVC吧。
Spring MVC是当前最优秀的MVC框架,自从Spring 2.5版本发布后,由于支持注解配置,易用性有了大幅度的提高。Spring 3.0更加完善,实现了对Struts 2的超越。现在越来越多的开发团队选择了Spring MVC。
Struts2也是非常优秀的MVC构架,优点非常多比如良好的结构,拦截器的思想,丰富的功能。但这里想说的是缺点,Struts2由于采用了值栈、OGNL表达式、struts2标签库等,会导致应用的性能下降,应避免使用这些功能。而Struts2的多层拦截器、多实例action性能都很好。可以参考我写的一篇关于Spring MVC与Struts2与Servlet比较的文章《Struts2、SpringMVC、Servlet(Jsp)性能对比 测试》
Spring3 MVC的优点: 1、Spring3 MVC使用简单,学习成本低。学习难度小于Struts2,Struts2用不上的多余功能太多。呵呵,当然这不是决定因素。 2、Spring3 MVC很容易就可以写出性能优秀的程序,Struts2要处处小心才可以写出性能优秀的程序(指MVC部分) 3、Spring3 MVC的灵活是你无法想像的,Spring框架的扩展性有口皆碑,Spring3 MVC当然也不会落后,不会因使用了MVC框架而感到有任何的限制。
Struts2的众多优点: 1、老牌的知名框架,从Struts1起积累了大量用户群体。技术文档丰富。 2、其它方面略... (呵呵,是不是不公平?)
Spring的官方下载网址是:http://www.springsource.org/download (本文使用是的Spring 3.0.5版本) 转载请注明出处:原文地址:http://elf8848.iteye.com/blog/875830
二、核心类与接口:
先来了解一下,几个重要的接口与类。现在不知道他们是干什么的没关系,先混个脸熟,为以后认识他们打个基础。
DispatcherServlet -- 前置控制器
HandlerMapping接口 -- 处理请求的映射 HandlerMapping接口的实现类: SimpleUrlHandlerMapping 通过配置文件,把一个URL映射到Controller DefaultAnnotationHandlerMapping 通过注解,把一个URL映射到Controller类上
HandlerAdapter接口 -- 处理请求的映射 AnnotationMethodHandlerAdapter类,通过注解,把一个URL映射到Controller类的方法上
Controller接口 -- 控制器 由于我们使用了@Controller注解,添加了@Controller注解注解的类就可以担任控制器(Action)的职责, 所以我们并没有用到这个接口。
HandlerInterceptor 接口--拦截器 无图,我们自己实现这个接口,来完成拦截的器的工作。
ViewResolver接口的实现类 UrlBasedViewResolver类 通过配置文件,把一个视图名交给到一个View来处理 InternalResourceViewResolver类,比上面的类,加入了JSTL的支持
View接口 JstlView类
LocalResolver接口
HandlerExceptionResolver接口 --异常处理 SimpleMappingExceptionResolver实现类
ModelAndView类 无图。
三、核心流程图
本图是我个人画的,有不严谨的地方,大家对付看吧。总比没的看强。 转载请注明出处:本文地址:http://elf8848.iteye.com/blog/875830
使用Spring MVC,配置DispatcherServlet是第一步。 DispatcherServlet是一个Servlet,所以可以配置多个DispatcherServlet。 DispatcherServlet是前置控制器,配置在web.xml文件中的。拦截匹配的请求,Servlet拦截匹配规则要自已定义,把拦截下来的请求,依据某某规则分发到目标Controller(我们写的Action)来处理。
“某某规则”:是根据你使用了哪个HandlerMapping接口的实现类的不同而不同。
先来看第一个例子: Xml代码![]()
在DispatcherServlet的初始化过程中,框架会在web应用的 WEB-INF文件夹下寻找名为[servlet-name]-servlet.xml 的配置文件,生成文件中定义的bean。
第二个例子: Xml代码![]() 指明了配置文件的文件名,不使用默认配置文件名,而使用springMVC.xml配置文件。 其中
这是最传统的方式,最简单也最实用。不会导致静态文件(jpg,js,css)被拦截。
2、拦截/,例如:/user/add 可以实现现在很流行的REST风格。很多互联网类型的应用很喜欢这种风格的URL。 弊端:会导致静态文件(jpg,js,css)被拦截后不能正常显示。想实现REST风格,事情就是麻烦一些。后面有解决办法还算简单。
3、拦截/*,这是一个错误的方式,请求可以走到Action中,但转到jsp时再次被拦截,不能访问到jsp。
转载请注明出处:本文地址:http://elf8848.iteye.com/blog/875830
五、父子上下文(WebApplicationContext)
如果你使用了listener监听器来加载配置,一般在Struts+Spring+Hibernate的项目中都是使用listener监听器的。如下 java代码![]()
Spring会创建一个WebApplicationContext上下文,称为父上下文(父容器) ,保存在 ServletContext中,key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE的值。 可以使用Spring提供的工具类取出上下文对象:WebApplicationContextUtils.getWebApplicationContext(ServletContext);
DispatcherServlet是一个Servlet,可以同时配置多个,每个 DispatcherServlet有一个自己的上下文对象(WebApplicationContext),称为子上下文(子容器),子上下文可以访问父上下文中的内容,但父上下文不能访问子上下文中的内容。 它也保存在 ServletContext中,key是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名称。当一个Request对象产生时,会把这个子上下文对象(WebApplicationContext)保存在Request对象中,key是DispatcherServlet.class.getName() + ".CONTEXT"。 可以使用工具类取出上下文对象:RequestContextUtils.getWebApplicationContext(request);
说明 :Spring 并没有限制我们,必须使用父子上下文。我们可以自己决定如何使用。
方案一,传统型: 父上下文容器中保存数据源、服务层、DAO层、事务的Bean。 子上下文容器中保存Mvc相关的Action的Bean. 事务控制在服务层。 由于父上下文容器不能访问子上下文容器中内容,事务的Bean在父上下文容器中,无法访问子上下文容器中内容,就无法对子上下文容器中Action进行AOP(事务)。 当然,做为“传统型”方案,也没有必要这要做。
方案二,激进型: Java世界的“面向接口编程”的思想是正确的,但在增删改查为主业务的系统里,Dao层接口,Dao层实现类,Service层接口,Service层实现类,Action父类,Action。再加上众多的O(vopobo)和jsp页面。写一个小功能 7、8个类就写出来了。 开发者说我就是想接点私活儿,和PHP,ASP抢抢饭碗,但我又是java程序员。最好的结果是大项目能做好,小项目能做快。所以“激进型”方案就出现了-----没有接口、没有Service层、还可以没有众多的O(vopobo)。那没有Service层事务控制在哪一层?只好上升的Action层。 本文不想说这是不是正确的思想,我想说的是Spring不会限制你这样做。 由于有了父子上下文,你将无法实现这一目标。解决方案是只使用子上下文容器,不要父上下文容器 。所以数据源、服务层、DAO层、事务的Bean、Action的Bean都放在子上下文容器中。就可以实现了,事务(注解事务)就正常工作了。这样才够激进。 总结:不使用listener监听器来加载spring的配置文件,只使用DispatcherServlet来加载spring的配置,不要父子上下文,只使用一个DispatcherServlet,事情就简单了,什么麻烦事儿也没有了。
Java--大项目能做好--按传统方式做,规规矩矩的做,好扩展,好维护。 Java--小项目能做快--按激进方式做,一周时间就可以出一个版本,先上线接受市场(用户)的反馈,再改进,再反馈,时间就是生命(成本)。
转载请注明出处:原文地址:http://elf8848.iteye.com/blog/875830
六、springMVC-mvc.xml 配置文件片段讲解 (未使用默认配置文件名) Xml代码 ![]()
@Controller 声明Action组件
如何替换
转载请注明出处:本文地址:http://elf8848.iteye.com/blog/875830
如何你的DispatcherServlet拦截"*.do"这样的有后缀的URL,就不存在访问不到静态资源的问题。
目的:可以正常访问静态文件,不可以找不到静态文件报404。 ![]() 要写在DispatcherServlet的前面, 让 defaultServlet先拦截请求,这样请求就不会进入Spring了,我想性能是最好的吧。
Tomcat, Jetty, JBoss, and GlassFish 自带的默认Servlet的名字 -- "default"
![]()
使用
方案三 ,使用 ![]() 会把"/**" url,注册到SimpleUrlHandlerMapping的urlMap中,把对静态资源的访问由HandlerMapping转到org.springframework.web.servlet.resource.DefaultServletHttpRequestHandler处理并返回.
补充说明:多个HandlerMapping的执行顺序问题: DefaultAnnotationHandlerMapping的order属性值是:0
spring会先执行order值比较小的。当访问一个a.jpg图片文件时,先通过 DefaultAnnotationHandlerMapping 来找处理器,一定是找不到的,因为我们没有叫a.jpg的Action。然后再按order值升序找,由于最后一个 SimpleUrlHandlerMapping 是匹配 "/**"的,所以一定会匹配上,就可以响应图片。
访问一个图片,还要走层层匹配。不知性能如何? 最后再说明一下,方案二、方案三 在访问静态资源时,如果有匹配的(近似)总拦截器,就会走拦截器。如果你在拦截中实现权限检查,要注意过滤这些对静态文件的请求。 如何你的DispatcherServlet拦截 *.do这样的URL后缀,就不存上述问题了。还是有后缀方便。
转载请注明出处:原文地址:http://elf8848.iteye.com/blog/875830
![]()
但前面我们配置了 如何替换
并在action类上使用: 转载请注明出处:原文地址:http://elf8848.iteye.com/blog/875830 org.springframework.web.servlet.handler.HandlerInterceptorAdapter适配器,
![]()
Spring MVC并没有总的拦截器,不能对所有的请求进行前后拦截。
![]() 为什么叫“近似”,前面说了,Spring没有总的拦截器。 如果是REST风格的URL,静态资源也会被拦截。
![]() 就是比 方案一多了一个URL匹配。 如果是REST风格的URL,静态资源也会被拦截。
方案三,HandlerMappint上的拦截器。 如果是REST风格的URL,静态资源就不会被拦截。因为我们精准的注入了拦截器。 Xml代码![]() 如果使用了 当然我们可以通过人工配置上面的两个Bean,不使用
其实我也不建议使用 如何替换 转载请注明出处:原文地址:http://elf8848.iteye.com/blog/875830
十一、如何实现全局的异常处理? 在spring MVC的配置文件中: Xml代码![]()
这里主要的类是SimpleMappingExceptionResolver类,和他的父类AbstractHandlerExceptionResolver类。 具体可以配置哪些属性,我是通过查看源码知道的。 你也可以实现HandlerExceptionResolver接口,写一个自己的异常处理程序。spring的扩展性是很好的。
通过SimpleMappingExceptionResolver我们可以将不同的异常映射到不同的jsp页面(通过exceptionMappings属性的配置)。
同时我们也可以为所有的异常指定一个默认的异常提示页面(通过defaultErrorView属性的配置),如果所抛出的异常在exceptionMappings中没有对应的映射,则Spring将用此默认配置显示异常信息。 注意这里配置的异常显示界面均仅包括主文件名,至于文件路径和后缀已经在viewResolver中指定。如/error/error表示/error/error.jsp
显示错误的jsp页面: html代码![]() 出错了<% Exception e = (Exception)request.getAttribute("exception"); out.print(e.getMessage()); %> |