您好,登錄后才能下訂單哦!
SpringMVC執行流程有哪些,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
還是之前的三個套路
Spring
提供一套視圖層的處理框架,他基于Servlet
實現,可以通過XML
或者注解進行我們需要的配置。
他提供了攔截器,文件上傳,CORS
等服務。
原生Servlet
在大型項目中需要進過多重封裝,來避免代碼冗余,其次由于不同接口需要的參數不同,我們需要自己在Servlet
層 封裝我們需要的參數,這對于開發者來說是一種重復且枯燥的工作,于是出現了視圖層框架,為我們進行參數封裝等功能。讓開發者的注意力全部放在邏輯架構中,不需要考慮參數封裝等問題。
再聊怎么用之前,我們需要了解一下MVC
的工作原理。
他基于一個DispatcherServlet
類實現對各種請求的轉發,即前端的所有請求都會來到這個Servlet中,然后這個類進行參數封裝和請求轉發,執行具體的邏輯。(第二章我們細聊)
根據上面的原理,我們需要一個DispatcherServlet
來為我們提供基礎的Servlet
服務,我們可以通過servlet
規范的web.xml
文件,對該類進行初始化。并且聲明該類處理所有的請求,然后通過這個類實現請求轉發。
另外,我們還需要一個配置文件,用來配置我們需要的相關的mvc
信息。
下面來看一個完整的web.xml
配置
<web-app> <servlet> <servlet-name>dispatchServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:springmvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatchServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> </web-app>
注解方式也是現在主流,SpringBoot
基于JavaConfig
實現了自動配置
實現方式:
在Servlet3.0
的時候定義了一個規范SPI
規范。
SPI
,全稱為 Service Provider Interface
,是一種服務發現機制。它通過在ClassPath
路徑下的META-INF/services
文件夾查找文件,自動加載文件里所定義的類。也就是在服務啟動的時候會Servlet會自動加載該文件定義的類
我們看一眼這個文件里的內容。他內部定義了SpringServletContainerInitializer
容器初始化類,也就是說在Servlet
啟動的時候會自動初始化這個類,這個類也是注解實現的關鍵。
這個類中存在一個onStartup
方法,這個也是當容器初始化的時候調用的方法,這個方法有兩參數
Set<class<?>> webAppInitializerClasses
他代表了當前我們的Spring
容器中存在的web
初始化類。我們自己可以通過實現WebApplicationInitializer
類來自定義Servlet
初始化的時候執行的方法。
ServletContext servletContex
代表了Servlet
上下文對象
org.springframework.web.SpringServletContainerInitializer
@HandlesTypes(WebApplicationInitializer.class) public class SpringServletContainerInitializer implements ServletContainerInitializer { @Override public void onStartup(Set<class<?>> webAppInitializerClasses, ServletContext servletContext) throws ServletException { //啟動邏輯 } }
具體看一下注解配置方式:
public class MyWebApplicationInitializer implements WebApplicationInitializer { @Override public void onStartup(ServletContext servletCxt) { // Load Spring web application configuration AnnotationConfigWebApplicationContext ac = new AnnotationConfigWebApplicationContext(); //一個配置類,@Configuration ac.register(AppConfig.class); //spring的那個refresh方法 ac.refresh(); // Create and register the DispatcherServlet DispatcherServlet servlet = new DispatcherServlet(ac); ServletRegistration.Dynamic registration = servletCxt.addServlet("app", servlet); registration.setLoadOnStartup(1); registration.addMapping("/app/*"); } }
通過實現WebApplicationInitializer
接口,來作為MVC
的配置類,在加載SpringServletContainerInitializer
的時候加載這個類。
不過在具體的實現中,Spring
不建議我們這樣做,他建議將Spring
和SpringMvc
分開,看個圖
他在Spring之上加了一層Web環境配置。相當于在Spring的外面包裝了一層Servlet
看一下此時的代碼
public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer { //Spring配置文件 @Override protected Class<!--?-->[] getRootConfigClasses() { return new Class<!--?-->[] { RootConfig.class }; } //SpringMVC的配置文件 @Override protected Class<!--?-->[] getServletConfigClasses() { return new Class<!--?-->[] { App1Config.class }; } //指定DispatcherServlet可以攔截的路徑 @Override protected String[] getServletMappings() { return new String[] { "/app1/*" }; } }
通過AbstractAnnotationConfigDispatcherServletInitializer
可以看到他實現了WebApplicationInitializer
接口,即在Servlet
初始化的時候會加載這個類。
AbstractContextLoaderInitializer
類,他初始化了Spring
AbstractDispatcherServletInitializer
類,初始化了DispatcherServlet
AbstractAnnotationConfigDispatcherServletInitializer
類,將兩個類整合到一起
聊這個原理之前,先來聊聊他要干什么?
需求:請求分發;參數封裝;結果返回
那如果我們自己來實現,該怎么辦?(單說注解,先來看看我們怎么使用MVC
的)
一個@Controller
注解,標識當前類為控制層接口,
一個RequestMapping
標識這個方法的URI
和請求方式等信息
一個@ResponseBody
標識這個方法的返回類型為JSON
一個test01
標識這個方法用來處理/test
請求
@Controller public class UserController { @GetMapping("/test") @ResponseBody public String test01(){ return "success" ; } }
接下來,我們通過我們已有的東西,看一下我們自己去處理請求的邏輯
先來想一下我們的請求過程:
前端發送一個Http
請求,通過不同的uri
實現不同邏輯的處理
而這個uri
和我們后端的定義的@RequestMapping
中的value
值相同
即我們可以通過一個Map
結構,將value
作為key
,將method
的Class
對象作為一個value
存到一個MappingRegister
中
請求來了以后,通過URI
從這個Map
中獲取相應的Method
執行,如果沒有對應的Method
給一個404
.
在上面的怎么用中提到了,他通過AbstractContextLoaderInitializer
來加載Spring
配置文件的。
此時關于Spring的東西已經加載好了,但并未進行初始化
同樣也是通過AbstractDispatcherServletInitializer
類實現
接下來我們具體看一下在這個期間,DispatcherServlet
如何處理請求的
作用:分發所有的請求
類繼承結構圖
可以看到他繼承了HttpServlet
類,屬于一個Servlet
,而在之前我們配置了這個Servlet
的攔截路徑。他會將所有的請求攔截,然后做一個分發。
下面這個圖各位看官應該非常熟悉:
其實DispatcherServlet
處理所有請求的方式在這個圖里完全都體現了。
接下來聊一下他的設計思路吧。
當一個請求來的時候,進入doDispatch
方法中,然后處理這個請求,也是返回一個執行鏈
Spring
提供了三種方式的處理器映射器來處理不同的請求。
BeanNameUrlHandlerMapping
處理單獨Bean
的請求。適用于實現Controller
和HttpRequestHandler
接口的類
@Component("/test02") public class HttpController implements Controller { @Override public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { System.out.println("HttpController執行"); return null; } }
@Component("/test01") public class HandlerController implements HttpRequestHandler { @Override public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { System.out.println("handlerRequest"); } }
RequestMappingHandlerMapping
適用于方法類型的處理器映射。
@Controller public class UserController { @GetMapping("/test") public String test01(){ System.out.println("執行了"); return "success" ; } }
RouterFunctionMapping
,MVC
提供的一個處理通過函數式編程定義控制器的一個映射器處理器。需要直接添加到容器中,然后 通過路由一個地址,返回對應的數據
@Configuration @ComponentScan("com.bywlstudio.controller") @EnableWebMvc public class MvcConfig implements WebMvcConfigurer { @Override public void configureViewResolvers(ViewResolverRegistry registry) { registry.jsp("/WEB-INF/pages/",".jsp"); } @Bean public RouterFunction<!--?--> routerFunctionA() { return RouterFunctions.route() .GET("/person/{id}", request1 -> ServerResponse.ok().body("Hello World")) .build(); } }
聊完了處理器映射器,再來聊一下處理器適配器
不同的請求方式,需要不同的處理方式,這也是Spring
為什么要提供一個適配器的原因。
RequestMappingHandlerAdapter
用來處理所有的方法請求,即通過@Controller
注解定義的
HandlerFunctionAdapter
用來處理函數式的映射,即通過RouterFunctionMapping
定義的
HttpRequestHandlerAdapter
用來處理實現了HttpRequestHandler
接口的
SimpleControllerHandlerAdapter
用來處理實現了Controller
接口的請求
通過處理器適配器拿到適合的處理器,來處理對應的請求。
在處理器執行具體的請求的過程,實際上就是調用我們的方法的過程,于是就會出現返回值
通常對于返回值我們有兩種方法:
@ResponseBody
直接返回JSON
數據。
或者返回一個視圖,該視圖會被視圖解析器解析。
對于返回值解析,MVC
提供了一個接口用于處理所有的返回值,這里我們僅僅談上面的兩種
ModelAndViewMethodReturnValueHandler
用于處理返回視圖模型的請求
RequestResponseBodyMethodProcessor
用于處理返回JSON
在我們拿到方法返回值以后,會調用this.returnValueHandlers.handleReturnValue
返回值解析器的這個方法,用于對視圖模型的返回和JSON
數據的回顯(直接回顯到網頁,此時返回的視圖對象為null)
對于視圖對象,通過視圖解析器直接解析,進行數據模型渲染,然后回顯給前端。
這個類存放了method
的映射信息。
class MappingRegistry { private final Map<t, mappingregistration<t>> registry = new HashMap<>(); private final Map<t, handlermethod> mappingLookup = new LinkedHashMap<>(); private final MultiValueMap<string, t> urlLookup = new LinkedMultiValueMap<>(); private final Map<string, list<handlermethod>> nameLookup = new ConcurrentHashMap<>(); private final Map<handlermethod, corsconfiguration> corsLookup = new ConcurrentHashMap<>(); private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
MVC
會從這個類中獲取方法和URL
的引用。相當于Spring MVC
的容器。
答:MVC
是一個架構模式,它有三個核心
視圖(View)。用戶界面
模型(Model)。業務數據
控制器(Controller)。接收用戶輸入,控制模型和視圖進行數據交互
MVVM
也是一種架構模式,它也是三個核心
模型(Model
)。后端數據
視圖模型(ViewModel
)。它完成了數據和視圖的綁定
視圖(View
)。用戶界面
它的核心思想是:通過ViewModel
將數據和視圖綁定,用數據操作視圖,常見框架為Vue
用戶發送請求至DispatcherServlet
DispatcherServelt
收到請求以后調用HandlerMapping
,找到請求處理器映射器(三選一)
通過處理器映射器對應URI
的處理器執行鏈(包含了攔截器,和處理器對象)
調用處理器適配器,找到可以處理該執行鏈的處理器(四選一)
處理器具體執行,返回ModelAndView
對象
如果存在@ResponseBody
注解,直接進行數據回顯
將返回的ModelAndView
對象傳給ViewResove
視圖解析器解析,返回視圖
DispatcherServlet
對View
進行渲染視圖
響應用戶
關于SpringMVC執行流程有哪些問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。