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的格式是否符合语法规范。等同于，生命了目标命名空间的模式文件

 

转载于:https://www.cnblogs.com/aguai1992/p/9341219.html