【Spring实战】构建Spring Web应用程序
本章内容：
- 映射请求到Spring控制器
- 透明地绑定表单参数
- 校验表单提交
状态管理、工作流以及验证都是Web 开发需要解决的重要特性。HTTP协议的无状态性决定了这些问题都不那么容易解决。
Spring的Web框架就是为了帮助解决这些关注点而设计的。Spring MVC基于模型-视图-控制器（Model-View-Controller，MVC）模式实现，它能构建像Spring框架那样灵活和松耦合的Web应用程序。
Spring MVC起步
Spring将请求在调度Servlet、处理器映射（handler mapping）、控制器以及视图解析器（view resolver）之间移动。
跟踪Spring MVC的请求
每当用户在Web浏览器中点击链接或提交表单的时候，请求就开始工作了。请求会将信息从一个地方带到另一个地方，就像是快递投送员。
从离开浏览器开始到获取响应返回，请求会经历好多站，在每站都会留下一些信息同时也会带上其他信息。
请求使用Spring MVC所经历的所有站点
在请求离开浏览器时 ①，会带有用户所请求内容的信息，比如请求的URL，用户提交的表单信息。
请求旅程的第一站是Spring的DispatcherServlet。与大多数基于Java的Web框架一样，Spring MVC所有的请求都会通过一个前端控制器（front controller）Servlet。
前端控制器是常用的Web应用程序模式，在这里一个单实例的Servlet将请求委托给应用程序的其他组件来执行实际的处理。在Spring MVC中，DispatcherServlet就是前端控制器。
DispatcherServlet的任务是将请求发送给Spring MVC控制器（controller）。控制器是一个用于处理请求的Spring组件。在典型的应用程序会有多个控制器，DispatcherServlet需要知道应该将请求发送给哪个控制器。所以DispatcherServlet以会查询一个或多个处理器映射（handler mapping）②来确定请求的下一站在哪里。处理器映射会根据请求所携带的URL信息来进行决策。
一旦选择了合适的控制器，DispatcherServlet会将请求发送给选中的控制器③ 。到了控制器，请求会卸下其负载（用户提交的信息）并等待控制器处理这些信息。（设计良好的控制器本身只处理很少甚至不处理工作，而是将业务逻辑委托给一个或多个服务对象进行处理。）
控制器在完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户并在浏览器上显示。这些信息被称为模型（model）。这些信息会以用户友好的方式进行格式化，一般会是HTML。所以，信息需要发送给一个视图（view），通常会是JSP。
控制器所做的最后一件事就是将模型数据打包，并且标示出用于渲染输出的视图名。接下来会将请求连同模型和视图名发送回DispatcherServlet ④。
这样控制器就不会与特定的视图相耦合，传递给DispatcherServlet的视图名并不直接表示某个特定的JSP。甚至并不能确定视图就是JSP。它仅仅传递了一个逻辑名称，这个名字将会用来查找产生结果的真正视图。DispatcherServlet将会使用视图解析器（view resolver）⑤来将逻辑视图名匹配为一个特定的视图实现。
DispatcherServlet知道由哪个视图渲染结果以后，请求的最后一站是视图的实现⑥，请求在这里交付模型数据。请求的任务完成。视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端⑦。
请求要经过很多的步骤，最终才能形成返回给客户端的响应。大多数的步骤都是在Spring框架内部完成的。
若不使用Spring MVC，则需要用户负责编写一个Dispatcher servlet，这个Dispatcher servlet要能做如下事情：
- 根据URI调用相应的action。
- 实例化正确的控制器类。
- 根据请求参数值来构造表单bean
- 调用控制器对象的相应方法。
- 转向到一个视图（JSP页面）。
搭建Spring MVC
借助于最近几个Spring新版本的功能增强，使用Spring MVC变得非常简单了。现在，使用最简单的方式来配置Spring MVC：所要实现的功能仅限于运行所创建的控制器。
配置DispatcherServlet
Spring MVC中提供了一个Dispatcher Servlet，它会调用控制器方法并转发到视图。DispatcherServlet是Spring MVC的核心。在这里请求会第一次接触到框架，它要负责将请求路由到其他的组件之中。
传统的方式，像DispatcherServlet这样的Servlet会配置在web.xml文件中，这个文件会放到应用的WAR包里面。
借助于Servlet 3规范和Spring 3.1的功能增强，这种方式已经不是唯一的方案了，可以使用Java将DispatcherServlet配置在Servlet容器中：
package spittr.config;
import org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer;
import spittr.web.WebConfig;
public class SpitterWebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected String[] getServletMappings() {
return new String[] { "/" };
}
@Override
protected Class<?>[] getRootConfigClasses() {
return new Class<?>[] { RootConfig.class };
}
@Override
protected Class<?>[] getServletConfigClasses() {
return new Class<?>[] { WebConfig.class };
}
}
扩展AbstractAnnotationConfigDispatcherServletInitializer的任意类都会自动地配置Dispatcher-Servlet和Spring应用上下文，Spring的应用上下文会位于应用程序的Servlet上下文之中。
AbstractAnnotationConfigDispatcherServletInitializer剖析
在Servlet 3.0环境中，容器会在类路径中查找实现
javax.servlet.ServletContainerInitializer接口的类，如果能发现的话，就会用它来配置Servlet容器。Spring提供了这个接口的实现，名为SpringServletContainerInitializer，这个类反过来又会查找实现WebApplicationInitializer的类并将配置的任务交给它们来完成。Spring 3.2引入了一个便利的WebApplicationInitializer基础实现，也就是AbstractAnnotationConfigDispatcherServletInitializer因为我们的Spittr-WebAppInitializer扩展了AbstractAnnotationConfigDispatcherServletInitializer（同时也就实现了WebApplicationInitializer），因此当部署到Servlet 3.0容器中的时候，容器会自动发现它，并用它来配置Servlet上下文。
尽管AbstractAnnotationConfigDispatcherServletInitializer的名字很长，但使用起来很简便。在上面的程序中，SpittrWebAppInitializer重写了三个方法。
第一个方法是getServletMappings()，它会将一个或多个路径映射到DispatcherServlet上。在本例中，它映射的是“/”，这表示它会是应用的默认Servlet。它会处理进入应用的所有请求。
要理解其他的两个方法，首先要理解DispatcherServlet和一个Servlet监听器（ContextLoaderListener）的关系。
两个应用上下文之间的故事
当DispatcherServlet启动的时候，它会创建Spring应用上下文，并加载配置文件或配置类中所声明的bean。getServletConfigClasses()方法中，指明DispatcherServlet加载应用上下文时，使用定义在WebConfig配置类（使用Java配置）中的bean。
但是在Spring Web应用中，通常还会有另外一个应用上下文。另外的这个应用上下文是由ContextLoaderListener创建的。
我们希望DispatcherServlet加载包含Web组件的bean，如控制器、视图解析器以及处理器映射，而ContextLoaderListener要加载应用中的其他bean。这些bean通常是驱动应用后端的中间层和数据层组件。
实际上，AbstractAnnotationConfigDispatcherServletInitializer会同时创建DispatcherServlet和ContextLoaderListener。GetServletConfigClasses()方法返回的带有@Configuration注解的类将会用来定义DispatcherServlet应用上下文中的bean。getRootConfigClasses()方法返回的带有@Configuration注解的类将会用来配置ContextLoaderListener创建的应用上下文中的bean。
如果按照这种方式配置DispatcherServlet，而不是使用web.xml的话，只能部署到支持Servlet 3.0的服务器中才能正常工作，如Tomcat 7或更高版本。
如果没有使用支持Servlet 3.0的服务器，就无法在AbstractAnnotationConfigDispatcherServletInitializer子类中配置DispatcherServlet，只能使用web.xml配置。
启用Spring MVC
启用Spring MVC组件的方法不仅一种。使用XML进行配置的，可以使用<mvc:annotation-driven>启用注解驱动的Spring MVC。
基于Java的配置，使用带有@EnableWebMvc注解的类：
package spittr.web;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
@Configuration
@EnableWebMvc
public class WebConfig {
}
但还有其他问题要解决：
- 没有配置视图解析器。Spring默认会使用
BeanNameView-Resolver，这个视图解析器会查找ID与视图名称匹配的bean，并且查找的bean要实现View接口，以这样的方式来解析视图。 - 没有启用组件扫描。Spring只能找到显式声明在配置类中的控制器。
-
DispatcherServlet会映射为应用的默认Servlet，所以它会处理所有的请求，包括对静态资源的请求，如图片和样式表（可能并不是想要的效果）。
需要为这个最小的Spring MVC配置再加上一些内容，从而让它变得真正有用。
package spittr.web;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.ViewResolver;
import org.springframework.web.servlet.config.annotation.DefaultServletHandlerConfigurer;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurerAdapter;
import org.springframework.web.servlet.view.InternalResourceViewResolver;
@Configuration
@EnableWebMvc
@ComponentScan("spittr.web")
public class WebConfig extends WebMvcConfigurerAdapter {
@Bean
public ViewResolver viewResolver() {
InternalResourceViewResolver resolver = new InternalResourceViewResolver();
resolver.setPrefix("/WEB-INF/views/");
resolver.setSuffix(".jsp");
return resolver;
}
@Override
public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
configurer.enable();
}
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
// TODO Auto-generated method stub
super.addResourceHandlers(registry);
}
}
WebConfig现在添加了@Component-Scan注解，因此将会扫描spitter.web包来查找组件。控制器如果带有@Controller注解，会使其成为组件扫描时的候选bean。不需要在配置类中显式声明任何的控制器。
接着，添加了一个ViewResolver bean。具体来讲，是InternalResourceViewResolver。它会查找JSP文件，在查找的时候，会在视图名称上加一个特定的前缀和后缀（例如，名为home的视图将会解析为/WEB-INF/views/home.jsp）。
新的WebConfig类还扩展了WebMvcConfigurerAdapter并重写了其configureDefaultServletHandling()方法。通过调用DefaultServletHandlerConfigurer的enable()方法，要求DispatcherServlet将对静态资源的请求转发到Servlet容器中默认的Servlet上，而不是使用DispatcherServlet本身来处理此类请求。
Web相关的配置通过DispatcherServlet创建的应用上下文都已经配置好了，因此现在的RootConfig相对很简单：
package spittr.config;
import java.util.regex.Pattern;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.ComponentScan.Filter;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import org.springframework.web.servlet.config.annotation.EnableWebMVC;
@Configuration
@ComponentScan(basePackages={"spitter"},
excludeFilters={
@Filter(type=FilterType.ANNOTATION, value=EnableWebMVC.class)
})
public class RootConfig {
}
RootConfig使用了@ComponentScan注解。这样的话，就有很多机会用非Web的组件来充实完善RootConfig。
现在，已经可以开始使用Spring MVC构建Web应用了。
Spittr应用简介
因为从Twitter借鉴了灵感并且通过Spring来进行实现，所以它就有了一个名字：Spitter。再进一步，应用网站命名中流行的模式，如Flickr，我们去掉字母e，这样的话，我们就将这个应用称为Spittr。这个名称也 有助于区分应用名称和领域类型，因为我们将会创建一个名为Spitter的领域类。
Spittr应用有两个基本的领域概念：Spitter（应用的用户）和Spittle（用户发布的简短状态更新）。当我们在书中完善Spittr应用的功能时，将会介绍这两个领域概念。在本章中，会构建应用的Web层，创建展现Spittle的控制器以及处理用户注册成为Spitter的表。
编写基本的控制器
在Spring MVC中，控制器只是方法上添加了@RequestMapping注解的类，这个注解声明了它们所要处理的请求。
假设控制器类要处理对“/”的请求，并渲染应用的首页：
package spittr.web;
import static org.springframework.web.bind.annotation.RequestMethod.*;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
public class HomeController {
@RequestMapping(value = "/", method = GET)
public String home(){
return "home";
}
}
HomeController是一个构造型（stereotype）的注解，它基于@Component注解，辅助实现组件扫描。因为HomeController带有@Controller注解，因此组件扫描器会自动找到HomeController，并将其声明为Spring应用上下文中的一个bean。
可以让HomeController带有@Component注解，效果相同，但是表意性会差一点。
HomeController唯一的一个方法，也就是home()方法，带有@RequestMapping注解。它的value属性指定了这个方法所要处理的请求路径，method属性细化了它所处理的HTTP方法。当收到对“/”的HTTP GET请求时，就会调用home()方法。
home()方法返回了一个String类型的“home”。这个String将会被Spring MVC解读为要渲染的视图名称。DispatcherServlet会要求视图解析器将这个逻辑名称解析为实际的视图。
根据视图解析器InternalResourceViewResolver的配置，视图名“home”将会解析为“/WEB-INF/views/home.jsp”路径的JSP。
定义一个简单的首页JSP文件：
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ page session="false" %>
<html>
<head>
<title>Spitter</title>
<link rel="stylesheet"
type="text/css"
href="<c:url value="/resources/style.css" />" >
</head>
<body>
<h1>Welcome to Spitter</h1>
<a href="<c:url value="/spittles" />">Spittles</a> |
<a href="<c:url value="/spitter/register" />">Register</a>
</body>
</html>
这个JSP提供了两个链接：一个是查看Spittle列表，另一个是在应用中进行注册。下图展现了此时的首页的样子：
运行效果
现在，对这个控制器发起一些请求，看一下它是否能够正常工作。测试控制器最直接的办法可能就是构建并部署应用，然后通过浏览器对其进行访问，但是自动化测试可提供更快的反馈和更一致的独立结果。
测试控制器
编写一个简单的类来测试HomeController：
package java.spittr.web;
import static org.junit.Assert.assertEquals;
import org.junit.Test;
import spittr.web.HomeController;
public class HomeControllerTest {
@Test
public void testHomePage() throws Exception {
HomeController controller = new HomeController();
assertEquals("home",controller.home());
}
}
代码只测试了home()方法中会发生什么。在测试中会直接调用home()方法，并断言返回包含“home”值的String。它完全没有站在Spring MVC控制器的视角进行测试。这个测试没有断言当接收到针对“/”的GET请求时会调用home()方法。因为它返回的值就是“home”，所以也没有真正判断home是视图的名称。
从Spring 3.2开始，我们可以按照控制器的方式来测试Spring MVC中的控制器了，而不仅仅是作为POJO进行测试。Spring现在包含了一种mock Spring MVC并针对控制器执行HTTP请求的机制。这样的话，在测试控制器的时候，就没有必要再启动Web服务器和Web浏览器了。
重写HomeControllerTest并使用Spring MVC中新的测试特性：
package spittr.web;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.*;
import org.junit.Test;
import org.springframework.test.web.servlet.MockMvc;
import spittr.web.HomeController;
public class HomeControllerTest {
@Test
public void testHomePage() throws Exception {
HomeController controller = new HomeController();
MockMvc mockMvc = standaloneSetup(controller).build();
mockMvc.perform(get("/")).andExpect(view().name("home"));
}
新版本的测试比之前更加完整地测试了HomeController。这次我们不是直接调用home()方法并测试它的返回值，而是发起了对“/”的GET请求，并断言结果视图的名称为home。它首先传递一个HomeController实例到MockMvcBuilders.standaloneSetup()并调用build()来构建MockMvc实例。然后它使用MockMvc实例来执行针对“/”的GET请求并设置期望得到的视图名称。
定义类级别的请求处理
拆分@RequestMapping，并将其路径映射部分放到类级别上：
package spittr.web;
import static org.springframework.web.bind.annotation.RequestMethod.*;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
@RequestMapping(value = "/")
public class HomeController {
@RequestMapping(method = GET)
public String home(){
return "home";
}
}
新版本的HomeController中，路径现在被转移到类级别的@RequestMapping上，而HTTP方法依然映射在方法级别上。当控制器在类级别上添加@RequestMapping注解时，这个注解会应用到控制器的所有处理器方法上。处理器方法上的@RequestMapping注解会对类级别上的@RequestMapping的声明进行补充。
HomeController只有一个控制器方法。与类级别的@Request-Mapping合并之后，这个方法的@RequestMapping表明home()将会处理对“/”路径的GET请求。
测试代码可以确保在这个修改过程中，没有对原有的功能造成破坏。
当我们在修改@RequestMapping时，还可以对HomeController做另外一个变更@RequestMapping的value属性能够接受一个String类型的数组。到目前为止，我们给它设置的都是一个String类型的“/”。但是，我们还可以将它映射到对“/homepage”的请求，只需将类级别的@RequestMapping改为如下所示：
@Controller
@RequestMapping({"/", "/homepage"})
public class HomeController {
...
}
现在，HomeController的home()方法能够映射到对“/”和“/homepage”的GET请求。
传递模型数据到视图中
大多数的控制器并不像HomeController那么简单。在Spittr应用中，我们需要有一个页面展现最近提交的Spittle列表。因此，我们需要一个新的方法来处理这个页面。
首先，需要定义一个数据访问的Repository。为了实现解耦以及避免陷入数据库访问的细节之中，我们将Repository定义为一个接口，并在稍后实现它（第10章中）。此时，我们只需要一个能够获取Spittle列表的Repository，如下所示的SpittleRepository功能已经足够了：
package spittr.data;
import java.util.List;
import spittr.Spittle;
public interface SpittleRepository {
List<Spittle> findSpittles(long max, int count);
}
findSpittles()方法接受两个参数。其中max参数代表所返回的Spittle中，Spittle ID属性的最大值，而count参数表明要返回多少个Spittle对象。为了获得最新的20个Spittle对象，我们可以这样调用findSpittles()：
List<Spittle> recent = spittleRepository.findSpittles(Long.MAX_VALUE,20);
现在，定义一个Spittle类，让Spittle类尽可能的简单。它的属性包括消息内容、时间戳以及Spittle发布时对应的经纬度：
package spittr;
import java.util.Date;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
public class Spittle {
private final Long id;
private final String message;
private final Date time;
private Double latitude;
private Double longitude;
public Spittle(String message, Date time){
this(message,time,null,null);
}
public Spittle(String message, Date time, Double latitude, Double longitude){
this.id = null;
this.message = message;
this.time = time;
this.longitude = longitude;
this.latitude = latitude;
}
public Long getId() {
return id;
}
public String getMessage() {
return message;
}
public Date getTime() {
return time;
}
public Double getLatitude() {
return latitude;
}
public Double getLongitude() {
return longitude;
}
@Override
public boolean equals(Object that){
return EqualsBuilder.reflectionEquals(this, that, "id", "time")
}
@Override
public int hashCode(){
return HashCodeBuilder.reflectionHashCode(this, "id", "time")
}
}
就大部分内容来看，Spittle就是一个基本的POJO数据对象没有什么复杂的。唯一要注意的是，我们使用Apache Common Lang包来实现equals()和hashCode()方法。这些方法除了常规的作用以外，当我们为控制器的处理器方法编写测试时，它们也是有用的。
使用Spring的MockMvc来断言新的处理器方法中所期望的行为：
@Test
public void shouldShowRecentSpittles() throws Exception {
List<Spittle> expectedSpittles = createSpittleList(20);
SpittleRepository mockRepository =
mock(SpittleRepository.class);
when(mockRepository.findSpittles(Long.MAX_VALUE,20))
.thenReturn(expectedSpittles);
SpittleController controller = new SpittleController(mockRepository);
MockMvc mockMvc = standaloneSetup(controller).setSingleView(
new InternalResourceView("/WEB-INF/views/spittles.jsp"))
.build();
mockMvc.perform(get("/spittles"))
.andExpect(view().name("spittles"))
.andExpect(model().attributeExists("spittleList"))
.andExpect(model().attribute("spittleList",
hasItems(expectedSpittles.toArray())));
}
. . .
private List<Spittle> createSpittleList(int count) {
List<Spittle> spittles = new ArrayList<Spittle>();
for (int i = 0; i < count ; i++) {
spittles.add(new Spittle("Spittle " + i, new Date()));
}
return spittles;
}
这个测试首先会创建SpittleRepository接口的mock实现，这个实现会从它的findSpittles()方法中返回20个Spittle对象。然后，它将这个Repository注入到一个新的SpittleController实例中，然后创建MockMvc并使用这个控制器。
这个测试在MockMvc构造器上调用了setSingleView()。这样的话，mock框架就不用解析控制器中的视图名了。在很多场景中，其实没有必要这样做。但是对于这个控制器方法，视图名与请求路径是非常相似的，这样按照默认的视图解析规则时，MockMvc就会发生失败，因为无法区分视图路径和控制器的路径。在这个测试中，构建InternalResourceView时所设置的实际路径是无关紧要的，但我们将其设置为与InternalResourceViewResolver配置一致。
这个测试对“/spittles”发起GET请求，然后断言视图的名称为spittles并且模型中包含名为spittleList的属性，在spittleList中包含预期的内容。
如果此时运行测试的话，它将会失败。它不是运行失败，而是在编译的时候就会失败。这是因为我们还没有编写SpittleController。现在创建一个SpittleController：
package spittr.web;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import spittr.data.SpittleRepository;
@Controller
@RequestMapping("/spittles")
public class SpittleController {
private SpittleRepository spittleRepository;
@Autowired
public SpittleController(SpittleRepository spittleRepository) {
this.spittleRepository = spittleRepository;
}
@RequestMapping(method = RequestMethod.GET)
public String spittles(Model model) {
model.addAttribute(spittleRepository.findSpittles(Long.MAX_VALUE, 20));
return "spittles";
}
}
可以看到SpittleController有一个构造器，这个构造器使用了@Autowired注解，用来注入SpittleRepository。这个SpittleRepository又用在spittles()方法中，用来获取最新的spittle列表。
在spittles()方法中给定了一个Model作为参数。这样，spittles()方法就能将Repository中获取到的Spittle列表填充到模型中。Model实际上就是一个Map（也就是key-value对的集合），它会传递给视图，这样数据就能渲染到客户端了。当调用addAttribute()方法并且不指定key的时候，那么key会根据值的对象类型推断确定。在本例中，因为它是一个List<Spittle>，因此，键将会推断为spittleList。
spittles()方法所做的最后一件事是返回spittles作为视图的名字，这个视图会渲染模型。
如果希望显式声明模型的key的话，也可以这样进行指定：
@RequestMapping(method = RequestMethod.GET)
public String spittles(Model model) {
model.addAttribute("spittleList",
spittleRepository.findSpittles(Long.MAX_VALUE, 20));
return "spittles";
}
如果希望使用非Spring类型，可以用java.util.Map来代替Model：
@RequestMapping(method = RequestMethod.GET)
public String spittles(Map model) {
model.put("spittleList",
spittleRepository.findSpittles(Long.MAX_VALUE, 20));
return "spittles";
}
还有一种编写spittles()的方式：
@RequestMapping(method = RequestMethod.GET)
public List<Spittles> spittles() {
return spittleRepository.findSpittles(Long.MAX_COUNT, 20);
}
这个版本与其他的版本有些差别。它并没有返回视图名称，也没有显式地设定模型，这个方法返回的是Spittle列表。当处理器方法像这样返回对象或集合时，这个值会放到模型中，模型的key会根据其类型推断得出（在本例中，也就是spittleList）。
而逻辑视图的名称将会根据请求路径推断得出。因为这个方法处理针对“/spittles”的GET请求，因此视图的名称将会是spittles。
不管选择哪种方式来编写spittles()方法，所得到的结果都是相同的。模型中会存储一个Spittle列表，key为spittleList，然后这个列表会发送到名为spittles的视图中。按照我们配置InternalResourceViewResolver的方式，视图的JSP将会是“/WEB-INF/views/spittles.jsp”。
现在，数据已经放到了模型中，在JSP中该如何访问它呢？实际上，
当视图是JSP的时候，模型数据会作为请求属性放到请求（request）
之中。因此，在spittles.jsp文件中可以使用JSTL（JavaServer Pages
Standard Tag Library）的<c:forEach>标签渲染spittle列表：
<c:forEach items="${spittleList}" var="spittle" >
<li id="spittle_<c:out value="spittle.id"/>">
<div class="spittleMessage"><c:out value="${spittle.message}" /></div>
<div>
<span class="spittleTime"><c:out value="${spittle.time}" /></span>
<span class="spittleLocation">(<c:out value="${spittle.latitude}" />, <c:out value="${spittle.longitude}" />)</span>
</div>
</li>
</c:forEach>
运行结果如图，由于没有初始化数据，因此结果列表为空：
接受请求的输入
尽管SpittleController很简单，但是它依然比HomeController更进一步了。但没有处理任何形式的输入。现在，我们要扩展SpittleController，让它从客户端接受一些输入。
Spring MVC允许以多种方式将客户端中的数据传送到控制器的处理器方法中，包括：
- 查询参数（Query Parameter）。
- 表单参数（Form Parameter）。
- 路径变量（Path Variable）。
处理查询参数
带有查询参数的请求，这也是客户端往服务器端发送数据时，最简单和最直接的方式。
在Spittr应用中，我们可能需要处理的一件事就是展现分页的Spittle列表。在现在的SpittleController中，它只能展现最新的Spittle，没有办法向前翻页查看以前编写的Spittle历史记录。如果想让用户每次都能查看某一页的Spittle历史，那么就需要提供一种方式让用户传递参数进来，进而确定要展现哪些Spittle集合。
假设要查看某一页Spittle列表，这个列表会按照最新的Spittle在前的方式进行排序。因此，下一页中第一条的ID肯定会早于当前页最后一条的ID。所以，为了显示下一页的Spittle，我们需要将一个Spittle的ID传入进来，这个ID要恰好小于当前页最后一条Spittle的ID。另外，还可以传入一个参数来确定要展现的Spittle数量。
为了实现这个分页的功能，编写的处理器方法要接受如下的参数：
- before参数（表明结果中所有Spittle的ID均应该在这个值之前）。
- count参数（表明在结果中要包含的Spittle数量）。
首先添加一个测试，这个测试反映了新spittles()方法的功能。
@Test
public void shouldShowPagedSpittles() throws Exception {
List<Spittle> expectedSpittles = createSpittleList(50);
SpittleRepository mockRepository = mock(SpittleRepository.class);
when(mockRepository.findSpittles(238900, 50))
.thenReturn(expectedSpittles);
SpittleController controller = new SpittleController(mockRepository);
MockMvc mockMvc = standaloneSetup(controller)
.setSingleView(new InternalResourceView("/WEB-INF/views/spittles.jsp"))
.build();
mockMvc.perform(get("/spittles?max=238900&count=50"))
.andExpect(view().name("spittles"))
.andExpect(model().attributeExists("spittleList"))
.andExpect(model().attribute("spittleList",
hasItems(expectedSpittles.toArray())));
}
测试方法关键针对“/spittles”发送GET请求，同时还传入了max和count参数。它测试了这些参数存在时的处理器方法，而另一个测试方法则测试了没有这些参数时的情景。这两个测试就绪后，我们就能确保不管控制器发生什么样的变化，它都能够处理这两种类型的请求：
@RequestMapping(method=RequestMethod.GET)
public List<Spittle> spittles(
@RequestParam(value="max") long max,
@RequestParam(value="count") int count) {
return spittleRepository.findSpittles(max, count);
}
SpittleController中的处理器方法要同时处理有参数和没有参数的场景，需要对其进行修改，让它能接受参数，同时，如果这些参数在请求中不存在的话，就使用默认值Long.MAX_VALUE和20。@RequestParam注解的defaultValue属性可以完成这项任务：
@RequestMapping(method=RequestMethod.GET)
public List<Spittle> spittles(
@RequestParam(value="max", defaultValue=MAX_LONG_AS_STRING) long max,
@RequestParam(value="count", defaultValue="20") int count) {
return spittleRepository.findSpittles(max, count);
}
现在，如果max参数没有指定的话，它将会是Long类型的最大值。因为查询参数都是String类型的，因此defaultValue属性需要String类型的值。因此，使用Long.MAX_VALUE是不行的。我们可以将Long.MAX_VALUE转换为名为MAX_LONG_-AS_STRING的String类型常量：
private static final String MAX_LONG_AS_STRING =
Long.toString(Long.MAX_VALUE);
尽管defaultValue属性给定的是String类型的值，但是当绑定到
方法的max参数时，它会转换为Long类型。
如果请求中没有count参数，count参数会被设为默认值20。
通过路径参数接受输入
在构建面向资源的控制器时，这种方式就是将传递参数作为请求路径的一部分，实现信息的输入。
假设应用程序需要根据给定的ID来展现某一个Spittle记录。其中一种方案就是编写处理器方法，通过使用@RequestParam注解，让它接受ID作为查询参数：
@RequestMapping(value="/show", method=RequestMethod.GET)
public String showSpittle(
@RequestParam("spittle_id") long spittleId,
Model model) {
model.addAttribute(spittleRepository.findOne(spittleId));
return "spittle";
}
这个处理器方法将会处理形如“/spittles/show?spittle_id=12345”这样的请求。尽管这也可以正常工作，但是从面向资源的角度来看这并不理想。理想情况下，要识别的资源（Spittle）应该通过URL路径进行标示，而不是通过查询参数。对“/spittles/12345”发起GET请求要优于对“/spittles/show?spittle_id=12345”发起请求。前者能够识别出要查询的资源，而后者描述的是带有参数的一个操作——本质上是通过HTTP发起的RPC。
现在将这个需求转换为一个测试：
@Test
public void testSpittle() throws Exception {
Spittle expectedSpittle = new Spittle("Hello", new Date());
SpittleRepository mockRepository = mock(SpittleRepository.class);
when(mockRepository.findOne(12345)).thenReturn(expectedSpittle);
SpittleController controller = new SpittleController(mockRepository);
MockMvc mockMvc = standaloneSetup(controller).build();
mockMvc.perform(get("/spittles/12345"))
.andExpect(view().name("spittle"))
.andExpect(model().attributeExists("spittle"))
.andExpect(model().attribute("spittle", expectedSpittle));
}
这个测试构建了一个mock Repository、一个控制器和MockMvc，这与本章中我们所编写的其他测试很类似。这个测试的最后几行，它对“/spittles/12345”发起GET请求，然后断言视图的名称是spittle，并且预期的Spittle对象放到了模型之中。由于我们还没有为这种请求实现处理器方法，因此这个请求将会失败。但是，可以通过为SpittleController添加新的方法来修正这个失败的测试。
到目前为止，在我们编写的控制器中，所有的方法都映射到了（通过@RequestMapping）静态定义好的路径上。但是，如果想让这个测试通过的话，我们编写的@RequestMapping要包含变量部分，这部分代表了Spittle ID。
为了实现这种路径变量，Spring MVC允许我们在@RequestMapping路径中添加占位符。占位符的名称要用大括号（“{”和“}”）括起来。路径中的其他部分要与所处理的请求完全匹配，但是占位符部分可以是任意的值。
下面的处理器方法使用了占位符，将Spittle ID作为路径的一部分：
@RequestMapping(value="/{spittleId}", method=RequestMethod.GET)
public String spittle(
@PathVariable("spittleId") long spittleId,
Model model) {
model.addAttribute(spittleRepository.findOne(spittleId));
return "spittle";
}
spittle()方法的spittleId参数上添加了@PathVariable("spittleId")注解，这表明在请求路径中，不管占位符部分的值是什么都会传递到处理器方法的spittleId参数中。如果对“/spittles/54321”发送GET请求，那么将会把“54321”传递进来，作为spittleId的值。
因为方法的参数名碰巧与占位符的名称相同，因此可以去掉@PathVariable中的value属性：
@RequestMapping(value="/{spittleId}", method=RequestMethod.GET)
public String spittle(
@PathVariable long spittleId, Model model) {
model.addAttribute(spittleRepository.findOne(spittleId));
return "spittle";
}
如果@PathVariable中没有value属性，它会假设占位符的名称与方法的参数名相同。这能够让代码稍微简洁一些。但如果你想要重命名参数时，必须要同时修改占位符的名称，使其互相匹配。
spittle()方法会将参数传递到SpittleRepository的findOne()方法中，用来获取某个Spittle对象，然后将Spittle对象添加到模型中。模型的key将会是spittle，这是根据传递到addAttribute()方法中的类型推断得到的。
这样Spittle对象中的数据就可以渲染到视图中了，此时需要引用请求中key为spittle的属性（与模型的key一致）。渲染Spittle的JSP视图片段如下：
<div class="spittleView">
<div class="spittleMessage"><c:out value="${spittle.message}" /></div>
<div>
<span class="spittleTime"><c:out value="${spittle.time}" /></span>
</div>
</div>
如果传递请求中少量的数据，查询参数和路径变量是很合适的。但通常还需要传递很多的数据（也许是表单提交的数据），那查询参数显得有些笨拙和受限了。
处理表单
Web应用的功能通常并不局限于为用户推送内容。大多数的应用允许用户填充表单并将数据提交回应用中，通过这种方式实现与用户的交互。像提供内容一样，Spring MVC的控制器也为表单处理提供了良好的支持。
使用表单分为两个方面：展现表单以及处理用户通过表单提交的数据。在Spittr应用中，我们需要有个表单让新用户进行注册。SpitterController是一个新的控制器，目前只有一个请求处理的方法来展现注册表单。
package spittr.web;
import static org.springframework.web.bind.annotation.RequestMethod.*;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
@RequestMapping("/spitter")
public class SpitterController {
@RequestMapping(value = "/register", method = GET)
public String showRegistrationForm() {
return "registerForm";
}
}
showRegistrationForm()方法的@RequestMapping注解以及类级别上的@RequestMapping注解组合起来，声明了这个方法要处理的是针对“/spitter/register”的GET请求。按照配置InternalResourceViewResolver，这意味着会使用“/WEB-INF/ views/registerForm.jsp”这个JSP来渲染注册表单。
尽管showRegistrationForm()方法非常简单，但测试依然需要覆盖到它：
package spittr.web;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.*;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import org.junit.Test;
import org.springframework.test.web.servlet.MockMvc;
public class SpitterControllerTest {
@Test
public void shouldShowRegistration() throws Exception {
SpitterRepository mockRepository = mock(SpitterRepository.class);
SpitterController controller = new SpitterController(mockRepository);
MockMvc mockMvc = standaloneSetup(controller).build();
mockMvc.perform(get("/spitter/register"))
.andExpect(view().name("registerForm"));
}
对“/spitter/register”发送GET请求，然后断言结果的视图名为registerForm。
因为视图的名称为registerForm，所以JSP的名称需要为registerForm.jsp。这个JSP必须要包含一个HTML<form>标签，在这个标签中用户输入注册应用的信息：
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ page session="false" %>
<html>
<head>
<title>Spitter</title>
<link rel="stylesheet" type="text/css"
href="<c:url value="/resources/style.css" />" >
</head>
<body>
<h1>Register</h1>
<form method="POST">
First Name: <input type="text" name="firstName" /><br/>
Last Name: <input type="text" name="lastName" /><br/>
Email: <input type="email" name="email" /><br/>
Username: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="submit" value="Register" />
</form>
</body>
</html>
表单域中记录用户的名字、姓氏、用户名以及密码，还包含一个提交表单的按钮。在浏览器渲染之后，它的样子如下所示。
这里的<form>标签中并没有设置action属性。在这种情况下，当表单提交时，会提交到与展现时相同的URL路径上。即提交到“/spitter/register”上。
意味着要在服务器端处理该HTTP POST请求。需要在Spitter-Controller中再添加一个方法来处理这个表单提交。
编写处理表单的控制器
当处理注册表单的POST请求时，控制器需要接受表单数据并将表单数据保存为Spitter对象。为了防止重复提交，应该将浏览器重定向到新创建用户的基本信息页面。这些行为通过下面的shouldProcessRegistration()进行了测试：
@Test
public void shouProcessRegistration() throws Exception{
SpitterRepository mockRepository = mock(SpitterRepository.class);
Spitter unsaved = new Spitter("jbauer", "24hours", "Jack", "Bauer", "jbauer@ctu.gov");
Spitter saved = new Spitter(24L, "jbauer", "24hours", "Jack", "Bauer", "jbauer@ctu.gov");
when(mockRepository.save(unsaved)).thenReturn(saved);
SpitterController controller = new SpitterController(mockRepository);
MockMvc mockMvc = standaloneSetup(controller).build();
mockMvc.perform(post("/spitter/register")
.param("firstName", "Jack")
.param("lastName", "Bauer")
.param("username", "jbauer")
.param("password", "24hours")
.param("email", "jbauer@ctu.gov"))
.andExpect(redirectedUrl("/spitter/jbauer"));
verify(mockRepository, atLeastOnce()).save(unsaved);
}
在构建完SpitterRepository的mock实现以及所要执行的控制器和MockMvc之后，shouldProcess-Registration()对“/spitter/register”发起了一个POST请求。作为请求的一部分，用户信息以参数的形式放到request中，从而模拟提交的表单。
在处理POST类型的请求时，在请求处理完成后，最好进行一下重定向，这样浏览器的刷新就不会重复提交表单了。在这个测试中，预期请求会重定到“/spitter/jbauer”，也就是新建用户的基本信息页面。
最后，测试会校验SpitterRepository的mock实现最终会真正用来保存表单上传入的数据。
通过shouldProcessRegistration()方法实现处理表单提交的控制器方法：
package spittr.web;
import static org.springframework.web.bind.annotation.RequestMethod.*;
import javax.validation.Valid;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.validation.Errors;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import spittr.Spitter;
import spittr.data.SpitterRepository;
@Controller
@RequestMapping("/spitter")
public class SpitterController {
private SpitterRepository spitterRepository;
@Autowired
public SpitterController(SpitterRepository spitterRepository) {
this.spitterRepository = spitterRepository;
}
@RequestMapping(value="/register", method=GET)
public String showRegistrationForm() {
return "registerForm";
}
@RequestMapping(value="/register", method=POST)
public String processRegistration(
@Valid Spitter spitter,
Errors errors) {
if (errors.hasErrors()) {
return "registerForm";
}
spitterRepository.save(spitter);
return "redirect:/spitter/" + spitter.getUsername();
}
@RequestMapping(value="/{username}", method=GET)
public String showSpitterProfile(@PathVariable String username, Model model) {
Spitter spitter = spitterRepository.findByUsername(username);
model.addAttribute(spitter);
return "profile";
}
}
新创建的processRegistration()方法，它接受一个Spitter对象作为参数。这个对象有firstName、lastName、username和password属性，这些属性将会使用请求中同名的参数进行填充。
当使用Spitter对象调用processRegistration()方法时，它会调用SpitterRepository的save()方法，SpitterRepository是在SpitterController的构造器中注入进来的。
processRegistration()方法最后返回一个String类型，用来指定视图。但是这个视图格式和以前我们所看到的视图有所不同。不仅返回了视图的名称供视图解析器查找目标视图，返回的值还带有重定向的格式。
当InternalResourceViewResolver看到视图格式中的“redirect:”前缀时，它就知道要将其解析为重定向的规则，而不是视图的名称。
本例中，它将会重定向到用户基本信息的页面。
除了“redirect:”，InternalResourceViewResolver还能识别“forward:”前缀。当它发现视图格式中以“forward:”作为前缀时，请求将会前往（forward）指定的URL路径，而不是重定向。
尽管HttpServletResponse.sendRedirect方法和RequestDispatcher.forward方法都可以让浏览器获 得另外一个URL所指向的资源，但两者的内部运行机制有着很大的区别。
Forward和Redirect代表了两种请求转发方式：直接转发和间接转发。
- 直接转发方式（Forward），客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。转发页面和转发到的页面可以共享request的数据。
- 间接转发方式（Redirect）实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。转发页面和转发到的页面不能共享request的数据。
因为我们重定向到了用户基本信息页面，那么我们应该往SpitterController中添加一个处理器方法showSpitterProfile()，用来处理对基本信息页面的请求：
@RequestMapping(value="/{username}", method=GET)
public String showSpitterProfile(@PathVariable String username, Model model) {
Spitter spitter = spitterRepository.findByUsername(username);
model.addAttribute(spitter);
return "profile";
}
SpitterRepository通过用户名获取一个Spitter对象，showSpitter-Profile()得到这个对象并将其添加到模型中，然后返回profile，也就是基本信息页面的逻辑视图名。基本信息视图实现如下：
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ page session="false" %>
<html>
<head>
<title>Spitter</title>
<link rel="stylesheet" type="text/css" href="<c:url value="/resources/style.css" />" >
</head>
<body>
<h1>Your Profile</h1>
<c:out value="${spitter.username}" /><br/>
<c:out value="${spitter.firstName}" /> <c:out value="${spitter.lastName}" /><br/>
<c:out value="${spitter.email}" />
</body>
</html>
基本信息视图渲染效果如下图所示：
如果表单中没有发送username或password的话，如果firstName或lastName的值为空或太长的话，程序会出现问题，为此需要为表单提交添加校验，避免数据呈现的不一致性。
校验表单
如果用户在提交表单的时候，username或password文本域为空的话，会导致在新建Spitter对象中，username或password是空的String。如果这种现象不处理的话，这将会出现安全问题，不管是谁只要提交一个空的表单就能登录应用。
同时应该阻止用户提交空的firstName和/或lastName，使应用仅在一定程度上保持匿名性。可以限制这些输入域值的长度，保持它们的值在一个合理的长度范围，避免这些输入域的误用。
从Spring 3.0开始，在Spring MVC中提供了对Java校验API的支持。在Spring MVC中使用Java校验API，不需要什么额外的配置。只要保证在类路径下包含这个Java API的实现即可，比如Hibernate Validator。
Java校验API定义了多个注解，这些注解可以放到属性上，从而限制这些属性的值。所有的注解都位于javax.validation.constraints包中。下表列出了这些校验注解：
除了表中的注解，Java校验API的实现可能还会提供额外的校验注解。同时，也可以定义自己的限制条件。
修改Spitter类，为属性添加校验注解：
package spittr;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
public class Spitter {
private Long id;
@NotNull
@Size(min=5, max=16)
private String username;
@NotNull
@Size(min=5, max=25)
private String password;
@NotNull
@Size(min=2, max=30)
private String firstName;
@NotNull
@Size(min=2, max=30)
private String lastName;
. . .
}
现在，Spitter的所有属性都添加了@NotNull注解，以确保它们的值不为null。属性上也添加了@Size注解以限制它们的长度在最大值和最小值之间。对Spittr应用来说，这意味着用户必须要填完注册表单，并且值的长度要在给定的范围内。
接下来要修改processRegistration()方法来应用校验功能。启用校验功能的processRegistration()如下所示：
@RequestMapping(value="/register", method=POST)
public String processRegistration(
@Valid Spitter spitter,
Errors errors) {
if (errors.hasErrors()) {
return "registerForm";
}
spitterRepository.save(spitter);
return "redirect:/spitter/" + spitter.getUsername();
}
Spitter参数添加了@Valid注解，这会告知Spring，需要确保这个对象满足校验限制。
在Spitter属性上添加校验限制并不能阻止表单提交。即便用户输入不符合规范
，processRegistration()方法依然会被调用。
如果有校验出现错误的话，那么这些错误可以通过Errors对象进行访问，现在这个对象作为processRegistration()方法的参数。（需要注意，Errors参数要紧跟在带有@Valid注解的参数后面。）
processRegistration()方法所做的第一件事就是调用Errors.hasErrors()来检查是否有错误。如果有错误的话，Errors.hasErrors()将会返回到registerForm，也就是注册表单的视图。这能够让用户的浏览器重新回到注册表单页面，所以他们能够修正错误，然后重新尝试提交。
如果没有错误的话，Spitter对象将会通过Repository进行保存，重定向到基本信息页面。
小结
Spring有一个强大灵活的Web框架。借助于注解，Spring MVC提供了近似于POJO的开发模式，这使得开发处理请求的控制器变得非常简单，同时也易于测试。
当编写控制器的处理器方法时，Spring MVC极其灵活。如果你的处理器方法需要内容的话，只需将对应的对象作为参数，而它不需要的内容，则没有必要出现在参数列表中。这样，就为请求处理带来了无限的可能性，同时还能保持一种简单的编程模型。
