【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要能做如下事情:

  1. 根据URI调用相应的action。
  2. 实例化正确的控制器类。
  3. 根据请求参数值来构造表单bean
  4. 调用控制器对象的相应方法。
  5. 转向到一个视图(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-ServletSpring应用上下文,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会同时创建DispatcherServletContextLoaderListenerGetServletConfigClasses()方法返回的带有@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()方法。通过调用DefaultServletHandlerConfigurerenable()方法,要求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 {
    ...
}

现在,HomeControllerhome()方法能够映射到对“/”和“/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极其灵活。如果你的处理器方法需要内容的话,只需将对应的对象作为参数,而它不需要的内容,则没有必要出现在参数列表中。这样,就为请求处理带来了无限的可能性,同时还能保持一种简单的编程模型。

推荐阅读更多精彩内容