Controller当中的参数与返回值

1.    ResponseBody

该注解直接将返回体转换为json格式的字符串，并返回

2.    RequestBody

该注解用于处理请求中的JSON类型，主要是将JSON绑定为一个bean

3.    RequestParam

在访问各类各样网站时，常常会发现网站的URL的最后一部分形如：？xxxx=yyyy&zzzz=wwww。这就是HTTP协议中的Request参数，它有什么用呢？先来看一个例子： 在知乎中搜索web 浏览器跳转到新页面后，URL变为https://www.zhihu.com/search?type=content&q=web 这里type=content&q=web就是搜索请求的参数，不一样参数之间用&分隔，每一个参数形如name=value形式，分别表示参数名字和参数值。在这个例子中，咱们输入不一样的搜索关键词，在搜索结果页面的URL的q参数是不一样的，也就是说，HTTP参数实际上能够认为是一种用户的输入，根据不一样的用户输入，服务器通过处理后返回不一样的输出（例如搜索spring和搜索java，显示结果是不同的。） getBlogList(@RequestParam(value="userId",required=false)Integer userId,HttpServletRequest request)

4.    PathVariable

相信你们可能注意到了，@RequestParam和@PathVariable都可以完成相似的功能——由于本质上，它们都是用户的输入，只不过输入的部分不一样，一个在URL路径部分，另外一个在参数部分。要访问一篇博客文章，这两种URL设计都是能够的： 经过@PathVariable，例如/blogs/1 经过@RequestParam，例如blogs?blogId=1 那么究竟应该选择哪种呢？建议： 当URL指向的是某一具体业务资源（或者资源列表），例如博客，用户时，使用@PathVariable 当URL须要对资源或者资源列表进行过滤，筛选时，用@RequestParam 例如咱们会这样设计URL： /blogs/{blogId} /blogs?state=publish而不是/blogs/state/publish来表示处于发布状态的博客文章

5.    resultType（属性名匹配）

使用resultType进行输出映射，只有查询出来的列名和pojo（实体bean）中的属性名一致，该列才能够映射成功。

若是查询出来的列名和pojo中的属性名所有不一致，没有建立pojo对象。

只要查询出来的列名和pojo中的属性有一个一致，就会建立pojo对象。

 

6.    resultMap（属性名重命名）

若是查询出来的列名和pojo的属性名不一致，经过定义一个resultMap对列名和pojo属性名之间做一个映射关系，例如此时是将User这个POJO设置为了映射

1. <resultMap type="user" id="userResultMap" type="com.entity.User">  
2.     <!-- id表示查询结果集中惟一标识   
3.     column:查询出的列名  
4.     property:type所指定的POJO中的属性名  
5.     最终reslutMap对column和property作一个映射关系(对应关系)  
6.     -->  
7.     <id column="_id" property="id"/>  
8.     <!-- 对普通列的映射定义 -->  
9.     <result column="_username" property="username"/>  

10. </resultMap>  

column表示查询出的列的名字，而property表示指定的POJO中的属性名

 

也可使用resultMap做为statement的输出映射类型

1. <!-- 使用resultMap进行输出映射   
2.     resultMap:指定定义的resultMap的id，若是这个resultMap在其它的mapper文件，前面须要加namespace  
3.     -->  
4. <select id="findUserByResultMap" parameterType="int" resultMap="userResultMap">  
5.     select id _id,username _username from user where id=#{value}  
6. </select>  

7.    @WebAppConfiguration

主要用户是在进行集成测试时，在针对controller的test上使用该注解，其用途是加载ApplicationContext上下文，保证启动一个上下文实例用于测试。

@WebAppConfiguration

@ContextConfiguration(classes = WebConfig.class)

public class EmployeeControllerTest {

    ...

}

 

在缺省参数的状况下

WebApplicationContext的加载地址被设置为src/main/webapp，即WAR应用的根目录

同理，咱们也能够修改该路径，从而修改该注解加载的目录

@WebAppConfiguration("src/test/webapp")

或者使用引用路径

@WebAppConfiguration("classpath:test-web-resources")

8.    xml的头部

<beans xmlns="http://www.springframework.org/schema/beans"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"

       xmlns:context="http://www.springframework.org/schema/context"

       xmlns:mvc="http://www.springframework.org/schema/mvc"

       xsi:schemaLocation="http://www.springframework.org/schema/beans

                        http://www.springframework.org/schema/beans/spring-beans-3.1.xsd

                        http://www.springframework.org/schema/context

                        http://www.springframework.org/schema/context/spring-context-3.1.xsd

                        http://www.springframework.org/schema/mvc

                        http://www.springframework.org/schema/mvc/spring-mvc-4.0.xsd">

 

l  xmlns 表示当前指定的命名空间

l  xmnls：xsi 指当前XML索要遵循的规范

l  而其后的p、context、mvc等都是后面xml内容中须要使用到的一个标签，每一个标签后面带了一个uri，这个uri不被XML自己所识别，只是做为一个命名来使用而已

l  xsi：schemaLocation 指定命名空间对应的验证文件，即每一个标签如p、context、mvc等的书写须要遵循对应配置的命名文件。有两部分组成，前面是命名空间URI，后面是xsd。此时IDEA工具能够解析和验证当前的xml的格式是否符合语法规范。等同于，生命了目标命名空间的模式文件