21.1Spring Web MVC框架介绍
Spring Web 模型-视图-控制器(MVC)框架是围绕DispatcherServlet设计的,可以把request(请求)分派到各handler(处理器)上,利用可配置的处理器映射,来支持如: 视图的解析,地区,时区,和主题的解析,同时也包括对文件上传的支持。默认的处理器基于@Controller和@RequestMapping注解,它们提供了多样且灵活的处理方法。在Spring3.0的介绍中,@Controller机制同样可以创建RESTful的网站或者应用,这些网站和应用可以通过@PathVariable注解和其他的一些特性来构建。
”开放扩展、封闭修改(开闭)“原则是Spring和Spring Web MVC的关键设计原则。
一些在Spring Web MVC中的核心类是被标注为final类型的,作为开发者是不能为了实现某种行为,而去覆盖这些方法。然而,这些原则还没有被草率地贯彻到Spring的设计中。但是请牢记这些准则。
当你使用Spring MVC时,不能在final方法中去做advice(AOP术语:通知),例如:你不能在AbstractController.setSynchronizeOnSession()这个方法中添加通知,若需要更多信息,请参考“理解AOP代理”这部分章节。
在Spring Web MVC中,你能利用任何对象作为一个指令或者一个form-backing object(具有类似表格组织背景的对象),你不需要去实现特定框架中的接口或者基础类,Spring的数据绑定是十分灵活的,例如:数据类型的不匹配会被程序作为验证上的错误,而不是作为系统上的错误被指出。因此,你不必为了处理无效的表单提交操作,或者为了把那些未输入的字符串做正确的转换,而在你的表单对象中去机械地复制你业务对象的属性和未输入的字符串,取而代之的是,在Spring Web MVC中,数据类型一般是直接绑定到你的业务对象上。
Spring的视图解析是非常灵活的,一般来说,一个Controller,可以准备好带有数据的(model)模型Map,再选择好一个指定的视图名来响应一个request请求,不仅如此,Controller也可以直接写入到response(响应)stream(数据流)中去完成request(请求)。视图名解析高度可配置,包括通过文件扩展,或者Accept header content type negotiation(HTTP的Accept报头内容类型协议),或者bean名称,一个properties(属性)文件,甚至于一个自定义的ViewResolver(视图解析器)实现来配置它。模型(MVC中的M)是一个Map接口,可以从视图技术中做出完整的抽象,你可以直接与基于模板的渲染技术,例如JSP,Velocity,Freemarker结合,或者直接与XML,JSON,Atom或者其他类型的内容结合,模型Map可以被轻易的转换为合适的格式,例如JSP中的request attributes(请求属性),Velocity的template model模板模型。
Spring Web MVC的特点
SpringWeb Flow
Spring WebFlow(SWF)旨在成为网络应用页面流程管理中最好的解决方案。
SWF与像Spring MVC、JSF之类的现有框架结合,包括Servlet和Portlet环境,如果你拥有与单纯的请求模型截然不同的业务处理需求,使用SWF可能是合适的解决方法。
SWF允许你获取在不同情况下可复用的逻辑页面流程。如此,搭建一个需要通过可控制的导航去引导用户完成业务过程时,使用SWF是十分理想的。
如要了解关于SWF的更多信息,请参阅SWF网站。
Spring的web模块包括许多特别的web支持特点:
- 清晰的角色分离,每一个角色——controller(控制器),validator(验证器),command object(命令对象),form object(表单对象),model object(模型对象),DispatcherServlet(分派Servlet),handler mapping(处理器映射),view resolver(视图解析器)等等都能被一个特定的对象所实现。
- 框架和应用类可以像JavaBean般被配置。这些配置功能包括了在不同context间引用,例如从web controllers(控制器)到业务对象,或者到(validator)验证器
- 可适性高,无侵入性,灵活性好。定义任何你需要的controller方法签名,在特定的方案中,可能需要一种参数注解(例如:@RequestParam, @RequestHeader, @PathVariable等等)
- 可复用的业务代码。利用已有的业务对象作为指令或者表单对象,而不是为了扩展一个特定的框架基础类,而去重复地复制业务代码。
- 可自定义的数据绑定和验证。类型不匹配被看作为应用级验证错误,以便使那些违规的值,不同地区的date类型日期数据,和数字绑定等等得以保留,而不是把一些只限定字符串的,由手工转换的表单对象当作业务对象。
- 可自定义的处理器映射和视图解析。处理器映射和视图解析策略的范围从简单的基于URL的配置,到复杂的,特定的解析策略都可以实现。Spring比起特定技术下实现的web MVC框架来说更灵活。
- 灵活的模型转换。支持包括名称,值,Map的模型转换,能更容易的与任何视图技术结合。
- 可自定义的地区,时区和主题解析,不论用不用Sping的标签库都可以支持JSP,JSTL,并且可以直接支持诸如Velocity等等此类技术。
- 强大易用的JSP标签库,Spring拥有一套被熟知的Spring标签库,提供如:数据绑定和主题等的支持。自定义标签能够使标记到的代码的灵活性最大化。如需要关于标签库的更多信息,请参阅第42章,Spring JSP标签库。
- JSP表单标签库,在Spring2.0中已经介绍过了,能够使在JSP写表单更加轻松。如果需要关于标签库的更多信息,请参阅第43章 Spring-form JSP标签库。
- 在现有HTTP request(请求)和HTTP session的生命周期范围下的bean,这不是Spring MVC里独有的特点,而是Spring MVC中,WebApplicationContext容器的特点。这些bean在这里的生效范围被称为Request,session,和global session。
与其他MVC框架共存的可插拔(灵活)性
在一些项目中,非Spring MVC的MVC实现技术可能会更切合项目需要,许多团队希望去权衡需要在此技术和工具上的投入,例如JSF。
如果你不想使用Spring Web MVC,但是想考虑使用其他Spring提供的解决方案的情况下,使用Spring,你能够轻而易举的与你所选择的任意其他web MVC框架技术相结合。通过ContextLoaderListener,你能够轻易的启动Spring的基础应用context,可以利用ServletContext属性(或者Spring的respective helper方法)来访问任何行为对象。由于要实现无插件化,所以Spring中无专门的集成应用是必要的。从web层的角度看,你只是简单地把Spring看作一个库,利用Spring的基础应用context的实例看作一个入口点。
你所注册好的bean和Spring服务在不使用Spring Web MVC的情况下也能触手可及。在这种情况下,Spring不与其他web框架竞争,它只是简单地涉及如:bean的配置、数据验证交换处理等等之类的许多纯web MVC框架中做不到的功能。因此,利用Spring作为中间件或数据访问件(比如:你只是想在像JDBC中进行事务抽象或者Hibernate中继承其功能的情况下),可以使你的应用更加丰富。