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的格式是否符合語法規範。等同於，生命了目標命名空間的模式文件