spring大亂燉

普通web--控制器就相似是一個調度員
觀察者設計模式,在模型上註冊視圖,當模型更新時自動更新視圖
用戶發送請求給前端控制器,前端控制器接收請求,委託給模型進行業務處理,
前臺控制器將數據返回給模型,而後選擇用來展現數據的視圖,將模型推送給視圖,
視圖展現數據,將響應返回給客戶。

spring MVC
請求--響應模型
模型沒法直接推送數據給視圖,若是客戶端但願看見視圖,須要再發一次請求。
    
前端控制器是DispatcherServlet
應用控制器其實拆爲處理器映射器(Handler Mapping)進行處理器管理和視圖解析器(View Resolver)進行視圖管理
頁面控制器/動做/處理器爲Controller接口(僅包含ModelAndView handleRequest(request, response) 方法)的實現(也能夠是任何的POJO類)

一、首先用戶發送請求————>前端控制器,前端控制器根據請求信息(如URL)來決定選擇哪個頁面控制器進行處理並把請求委託給它,即之前的控制器的控制邏輯部分;圖2-1中的一、2步驟;

二、頁面控制器接收到請求後,進行功能處理,首先須要收集和綁定請求參數到一個對象,這個對象在Spring Web MVC中叫命令對象,並進行驗證,而後將命令對象委託給業務對象進行處理;
      處理完畢後返回一個ModelAndView(模型數據和邏輯視圖名);圖2-1中的三、四、5步驟;

三、前端控制器收回控制權,而後根據返回的邏輯視圖名,選擇相應的視圖進行渲染,並把模型數據傳入以便視圖渲染;圖2-1中的步驟六、7;

四、前端控制器再次收回控制權,將響應返回給用戶,圖2-1中的步驟8;至此整個結束。

核心架構的具體流程步驟以下:

一、  首先用戶發送請求——>DispatcherServlet,前端控制器收到請求後本身不進行處理,而是委託給其餘的解析器進行處理,做爲統一訪問點,進行全局的流程控制;

二、  DispatcherServlet——>HandlerMapping, HandlerMapping將會把請求映射爲HandlerExecutionChain對象(包含一個Handler處理器(頁面控制器)對象、多個HandlerInterceptor攔截器)對象,
       經過這種策略模式,很容易添加新的映射策略;

三、  DispatcherServlet——>HandlerAdapter,HandlerAdapter將會把處理器包裝爲適配器,從而支持多種類型的處理器,即適配器設計模式的應用,從而很容易支持不少類型的處理器;

四、  HandlerAdapter——>處理器功能處理方法的調用,HandlerAdapter將會根據適配的結果調用真正的處理器的功能處理方法,完成功能處理;html

       並返回一個ModelAndView對象(包含模型數據、邏輯視圖名);

五、  ModelAndView的邏輯視圖名——> ViewResolver, ViewResolver將把邏輯視圖名解析爲具體的View,經過這種策略模式,很容易更換其餘視圖技術;

六、  View——>渲染,View會根據傳進來的Model模型數據進行渲染,此處的Model實際是一個Map數據結構,所以很容易支持其餘視圖技術;

七、  返回控制權給DispatcherServlet,由DispatcherServlet返回響應給用戶,到此一個流程結束。
----------問題-------
一、  請求如何給前端控制器?這個應該在web.xml中進行部署描述,在HelloWorld中詳細講解。

二、  前端控制器如何根據請求信息選擇頁面控制器進行功能處理? 咱們須要配置HandlerMapping進行映射

三、  如何支持多種頁面控制器呢?配置HandlerAdapter從而支持多種類型的頁面控制器

四、  如何頁面控制器如何使用業務對象?能夠預料到,確定利用Spring IoC容器的依賴注入功能

五、  頁面控制器如何返回模型數據?使用ModelAndView返回

六、  前端控制器如何根據頁面控制器返回的邏輯視圖名選擇具體的視圖進行渲染? 使用ViewResolver進行解析

七、  不一樣的視圖技術如何使用相應的模型數據? 由於Model是一個Map數據結構,很容易支持其餘視圖技術

-------------------------------------註解----------------------------------------------

@Service:用於標註業務層組件

@Controller:用於標註控制層組件(如struts中的action)

@Repository:用於標註數據訪問組件,即DAO組件

@Component:泛指組件,當組件很差歸類的時候,咱們可使用這個註解進行標註。
@Named:與@Component:存在細微的差距,基本上能夠互相替換,習慣上不會使用。

@Controller:用於標識是處理器類;

@ComponentScan:啓用組件掃描

1.component-scan標籤默認狀況下自動掃描指定路徑下的包(含全部子包),將帶有@Component、@Repository、@Service、@Controller標籤的類自動註冊到spring容器。
對標記了 Spring @Required、@Autowired、JSR250's @PostConstruct、@PreDestroy、@Resource、JAX-WS's
@WebServiceRef:EJB3's @EJB、JPA's @PersistenceContext、@PersistenceUnit等註解的類進行對應的操做使註解生效(包含了annotation-config標籤的做用)。

@Autowired:自動裝配---將組建掃描獲得的bean和它們的依賴裝配在一塊兒--spring特有註解
@Inject--存在細微的差距,基本上能夠互相替換--來源java依賴規範

@RequestMapping:請求處處理器功能方法的映射規則;
    將 HTTP 請求映射到 MVC 和 REST 控制器的處理方法上。
    Spring MVC 的 @RequestMapping 註解可以處理 HTTP 請求的方法, 好比 GET, PUT, POST, DELETE 以及 PATCH

@RequestParam:請求參數處處理器功能處理方法的方法參數上的綁定;

@RequestBody:請求的body體的綁定(經過HttpMessageConverter進行類型轉換);

@ResponseBody:處理器功能處理方法的返回值做爲響應體(經過HttpMessageConverter進行類型轉換);
    表示該方法的返回結果直接寫入HTTP response body中,通常在異步獲取數據時使用。
    在使用@RequestMapping後,返回值一般解析爲跳轉路徑。加上@responsebody後,返回結果直接寫入HTTP response body中,不會被解析爲跳轉路徑。
    好比異步請求,但願響應的結果是json數據,那麼加上@responsebody後,就會直接返回json數據。

@Configuration:可理解爲用spring的時候xml裏面的<beans>標籤:至關於把該類做爲spring的xml配置文件中的<beans>,做用爲:配置spring容器(應用上下文)
    
1.@Configuration不能夠是final類型;
2.@Configuration不能夠是匿名類;
3.嵌套的configuration必須是靜態類。

@GetMapping:組合註解,是@RequestMapping(method = RequestMethod.GET)的縮寫

@Bean:可理解爲用spring的時候xml裏面的<bean>標籤--通知spring這個方法將返回一個對象,該對象要註冊爲spring應用上下文中的bean,方法體中包含了最終產生Bean實例的邏輯

@Import:註解支持導入普通的java類,並將其聲明成一個bean--4.2以前只支持導入配置類

@ImportResource:經過locations屬性加載對應的xml配置文件,同時須要配合@Configuration註解一塊兒使用,定義爲配置類;

@Profile:指定某個bean屬於哪個profile--應用在類級別上--3.2開始也能夠應用在方法上

@ActiveProfiles:指定測試時要激活哪一個profile

@Conditional:條件化bean,條件爲true纔會建立

@Primary:指定首選的bean,解決自動裝配的歧義性
    能夠與@Component:組合用在組件掃描的bean上。
    能夠與@Bean:組合用在java配置的bean聲明中。
自定義註解:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface Log {
    //事件描述
    public String value() default "";
}

@Scope:spring bean的默認做用域是單利的(Singleton),若是要選擇其餘的做用域,須要使用scope註解。
    能夠與componant和bean註解一塊兒使用

處理外部值的最簡單方式就是聲明屬性源並經過Spring
的Environment來檢索屬性
@PropertySource引入源屬性文件:xxx.xml
@PropertySource註解和Environment屬性:
    environment.getProperty("");

@SuppressWarnings("unchecked")
    deprecation   使用了不同意使用的類或方法時的警告   
    unchecked     執行了未檢查的轉換時的警告,例如當使用集合時沒有用泛型 (Generics) 來指定集合保存的類型。   
    fallthrough   當 Switch 程序塊直接通往下一種狀況而沒有 Break 時的警告。   
    path          在類路徑、源文件路徑等中有不存在的路徑時的警告。    
    serial        當在可序列化的類上缺乏 serialVersionUID 定義時的警告。    
    finally       任何 finally 子句不能正常完成時的警告。   
    all           關於以上全部狀況的警告。

@ModelAttribute:請求參數到命令對象的綁定;

@SessionAttributes:用於聲明session級別存儲的屬性,放置在處理器類上,一般列出模型屬性(如@ModelAttribute)對應的名稱

@InitBinder:自定義數據綁定註冊支持,用於將請求參數轉換到命令對象屬性的對應類型;

Spring3.0引入RESTful架構風格支持(經過@PathVariable註解和一些其餘特性支持),且又引入了更多的註解支持:

@CookieValue:cookie數據處處理器功能處理方法的方法參數上的綁定;

@RequestHeader:請求頭(header)數據處處理器功能處理方法的方法參數上的綁定;

@ResponseStatus:定義處理器功能處理方法/異常處理器返回的狀態碼和緣由;

@ExceptionHandler:註解式聲明異常處理器;

@PathVariable:請求URI中的模板變量部分處處理器功能處理方法的方法參數上的綁定,從而支持RESTful架構風格的URI;

@Controller和@RestController的區別?

知識點:@RestController註解至關於@ResponseBody + @Controller合在一塊兒的做用。

1) 若是隻是使用@RestController註解Controller,則Controller中的方法沒法返回jsp頁面,或者html,配置的視圖解析器 InternalResourceViewResolver不起做用,返回的內容就是Return 裏的內容。

2) 若是須要返回到指定頁面,則須要用 @Controller配合視圖解析器InternalResourceViewResolver才行。
    若是須要返回JSON,XML或自定義mediaType內容到頁面,則須要在對應的方法上加上@ResponseBody註解。

例如:

1.使用@Controller 註解,在對應的方法上,視圖解析器能夠解析return 的jsp,html頁面,而且跳轉到相應頁面,若返回json等內容到頁面,則須要加@ResponseBody註解

2.@RestController註解,至關於@Controller+@ResponseBody兩個註解的結合,返回json數據不須要在方法前面加@ResponseBody註解了,但使用@RestController這個註解,就不能返回jsp,html頁面,視圖解析器沒法解析jsp,html頁面

**************************************************************************************************
若是返回到頁面是map或者json或者list等,加上@ResponseBody準沒錯,
若是你想跳轉到一個頁面,那麼千萬別加@ResponseBody,由於這個註解會將你返回的東西放到response的body數據中去,
換句話說,你返回的頁面將以字符串的形式寫到頁面上,而不是跳轉到這個頁面!
***************************************************************************************************

DispatcherServlet是前端控制器設計模式的實現,提供Spring Web MVC的集中訪問點,並且負責職責的分派,並且與Spring IoC容器無縫集成。
DispatcherServlet主要用做職責調度工做,自己主要用於控制流程,主要職責以下:

一、文件上傳解析,若是請求類型是multipart將經過MultipartResolver進行文件上傳解析;

二、經過HandlerMapping,將請求映射處處理器(返回一個HandlerExecutionChain,它包括一個處理器、多個HandlerInterceptor攔截器);

三、經過HandlerAdapter支持多種類型的處理器(HandlerExecutionChain中的處理器);

四、經過ViewResolver解析邏輯視圖名到具體視圖實現;

五、本地化解析;

六、渲染具體的視圖等;

七、若是執行過程當中遇到異常將交給HandlerExceptionResolver來解析。

-----DispatcherServlet中使用的特殊的Bean

-----DispatcherServlet默認使用WebApplicationContext做爲上下文,所以咱們來看一下該上下文中有哪些特殊的Bean:

一、Controller:處理器/頁面控制器,作的是MVC中的C的事情,但控制邏輯轉移到前端控制器了,用於對請求進行處理;

二、HandlerMapping:請求處處理器的映射,若是映射成功返回一個HandlerExecutionChain對象(包含一個Handler處理器(頁面控制器)對象、多個HandlerInterceptor攔截器)對象;如BeanNameUrlHandlerMapping將URL與Bean名字映射,映射成功的Bean就是此處的處理器;

三、HandlerAdapter:HandlerAdapter將會把處理器包裝爲適配器,從而支持多種類型的處理器,即適配器設計模式的應用,從而很容易支持不少類型的處理器;如SimpleControllerHandlerAdapter將對實現了Controller接口的Bean進行適配,而且掉處理器的handleRequest方法進行功能處理;

四、ViewResolver:ViewResolver將把邏輯視圖名解析爲具體的View,經過這種策略模式,很容易更換其餘視圖技術;如InternalResourceViewResolver將邏輯視圖名映射爲jsp視圖;

五、LocalResover:本地化解析,由於Spring支持國際化,所以LocalResover解析客戶端的Locale信息從而方便進行國際化;

六、ThemeResovler:主題解析,經過它來實現一個頁面多套風格,即常見的相似於軟件皮膚效果;

七、MultipartResolver:文件上傳解析,用於支持文件上傳;

八、HandlerExceptionResolver:處理器異常解析,能夠將異常映射到相應的統一錯誤界面,從而顯示用戶友好的界面(而不是給用戶看到具體的錯誤信息);

九、RequestToViewNameTranslator:當處理器沒有返回邏輯視圖名等相關信息時,自動將請求URL映射爲邏輯視圖名;

十、FlashMapManager:用於管理FlashMap的策略接口,FlashMap用於存儲一個請求的輸出,當進入另外一個請求時做爲該請求的輸入,一般用於重定向場景,後邊會細述

-------------------------------------springmvc與struts2的區別

1)入口

    springmvc的入口是一個servlet,即前端控制器,例如:*.action

    struts2入口是一個filter過慮器,即前端過濾器,例如:

2)單例、多例

    springmvc是基於方法開發,傳遞參數是經過方法形參,能夠設計爲單例

    struts2是基於類開發,傳遞參數是經過類的屬性,只能設計爲多例

3)參數傳遞

    springmvc經過參數解析器是將request對象內容進行解析成方法形參,將響應數據和頁面封裝成ModelAndView對象,最後又將模型數據經過request對象傳輸到頁面

    struts採用值棧存儲請求和響應的數據,經過OGNL存取數據

-------------spring事物配置,聲明式事務管理和基於@Transactional註解的使用
spring支持編程式事務管理和聲明式事務管理兩種方式。

    編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。對於編程式事務管理,spring推薦使用TransactionTemplate。

    聲明式事務管理創建在AOP之上的。其本質是對方法先後進行攔截,而後在目標方法開始以前建立或者加入一個事務,在執行完目標方法以後根據執行狀況提交或者回滾事務。
    聲明式事務最大的優勢就是不須要經過編程的方式管理事務,這樣就不須要在業務邏輯代碼中摻瑣事務管理的代碼,只需在配置文件中作相關的事務規則聲明(或經過基於@Transactional註解的方式),即可以將事務規則應用到業務邏輯中。

    顯然聲明式事務管理要優於編程式事務管理,這正是spring倡導的非侵入式的開發方式。聲明式事務管理使業務代碼不受污染,一個普通的POJO對象,只要加上註解就能夠得到徹底的事務支持。
    和編程式事務相比,聲明式事務惟一不足地方是,後者的最細粒度只能做用到「方法」級別,沒法作到像編程式事務那樣能夠做用到代碼塊級別。可是即使有這樣的需求,也存在不少變通的方法,
    好比,能夠將須要進行事務管理的代碼塊獨立爲方法等等。

    聲明式事務管理也有兩種經常使用的方式,一種是基於tx和aop名字空間的xml配置文件,另外一種就是基於@Transactional註解。顯然基於註解的方式更簡單易用,更清爽。

spring事務特性

spring全部的事務管理策略類都繼承自org.springframework.transaction.PlatformTransactionManager接口

其中TransactionDefinition接口定義如下特性:

事務隔離級別

  隔離級別是指若干個併發的事務之間的隔離程度。TransactionDefinition 接口中定義了五個表示隔離級別的常量:

    TransactionDefinition.ISOLATION_DEFAULT:這是默認值,表示使用底層數據庫的默認隔離級別。對大部分數據庫而言,一般這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
    TransactionDefinition.ISOLATION_READ_UNCOMMITTED:該隔離級別表示一個事務能夠讀取另外一個事務修改但尚未提交的數據。該級別不能防止髒讀,不可重複讀和幻讀,所以不多使用該隔離級別。好比PostgreSQL實際上並無此級別。
    TransactionDefinition.ISOLATION_READ_COMMITTED:該隔離級別表示一個事務只能讀取另外一個事務已經提交的數據。該級別能夠防止髒讀,這也是大多數狀況下的推薦值。
    TransactionDefinition.ISOLATION_REPEATABLE_READ:該隔離級別表示一個事務在整個過程當中能夠屢次重複執行某個查詢,而且每次返回的記錄都相同。該級別能夠防止髒讀和不可重複讀。
    TransactionDefinition.ISOLATION_SERIALIZABLE:全部的事務依次逐個執行,這樣事務之間就徹底不可能產生干擾,也就是說,該級別能夠防止髒讀、不可重複讀以及幻讀。可是這將嚴重影響程序的性能。一般狀況下也不會用到該級別。

事務傳播行爲

    所謂事務的傳播行爲是指,若是在開始當前事務以前,一個事務上下文已經存在,此時有若干選項能夠指定一個事務性方法的執行行爲。在TransactionDefinition定義中包括了以下幾個表示傳播行爲的常量:

    TransactionDefinition.PROPAGATION_REQUIRED:若是當前存在事務,則加入該事務;若是當前沒有事務,則建立一個新的事務。這是默認值。
    TransactionDefinition.PROPAGATION_REQUIRES_NEW:建立一個新的事務,若是當前存在事務,則把當前事務掛起。
    TransactionDefinition.PROPAGATION_SUPPORTS:若是當前存在事務,則加入該事務;若是當前沒有事務,則以非事務的方式繼續運行。
    TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事務方式運行,若是當前存在事務,則把當前事務掛起。
    TransactionDefinition.PROPAGATION_NEVER:以非事務方式運行,若是當前存在事務,則拋出異常。
    TransactionDefinition.PROPAGATION_MANDATORY:若是當前存在事務,則加入該事務;若是當前沒有事務,則拋出異常。
    TransactionDefinition.PROPAGATION_NESTED:若是當前存在事務,則建立一個事務做爲當前事務的嵌套事務來運行;若是當前沒有事務,則該取值等價於TransactionDefinition.PROPAGATION_REQUIRED。

事務超時

    所謂事務超時,就是指一個事務所容許執行的最長時間,若是超過該時間限制但事務尚未完成,則自動回滾事務。在 TransactionDefinition 中以 int 的值來表示超時時間,其單位是秒。

    默認設置爲底層事務系統的超時值,若是底層數據庫事務系統沒有設置超時值,那麼就是none,沒有超時限制。

事務只讀屬性

    只讀事務用於客戶代碼只讀但不修改數據的情形,只讀事務用於特定情景下的優化,好比使用Hibernate的時候。
    默認爲讀寫事務。

    「只讀事務」並非一個強制選項,它只是一個「暗示」,提示數據庫驅動程序和數據庫系統,這個事務並不包含更改數據的操做,那麼JDBC驅動程序和數據庫就有可能根據這種狀況對該事務進行一些特定的優化,比方說不安排相應的數據庫鎖,以減輕事務對數據庫的壓力,畢竟事務也是要消耗數據庫的資源的。

    可是你非要在「只讀事務」裏面修改數據,也並不是不能夠,只不過對於數據一致性的保護不像「讀寫事務」那樣保險而已。

    所以,「只讀事務」僅僅是一個性能優化的推薦配置而已,並不是強制你要這樣作不可


spring事務回滾規則

    指示spring事務管理器回滾一個事務的推薦方法是在當前事務的上下文內拋出異常。spring事務管理器會捕捉任何未處理的異常,而後依據規則決定是否回滾拋出異常的事務。

    默認配置下,spring只有在拋出的異常爲運行時unchecked異常時纔回滾該事務,也就是拋出的異常爲RuntimeException的子類(Errors也會致使事務回滾),而拋出checked異常則不會致使事務回滾。能夠明確的配置在拋出那些異常時回滾事務,包括checked異常。也能夠明肯定義那些異常拋出時不回滾事務。還能夠編程性的經過setRollbackOnly()方法來指示一個事務必須回滾,在調用完setRollbackOnly()後你所能執行的惟一操做就是回滾。

    myBatis爲例   基於註解的聲明式事務管理配置@Transactional前端

相關文章
相關標籤/搜索