SpringMVC核心流程圖
簡單總結(jié)
首先請求進入DispatcherServlet 由DispatcherServlet 從HandlerMappings中提取對應(yīng)的Handler
此時只是獲取到了對應(yīng)的Handle,然后得去尋找對應(yīng)的適配器,即:HandlerAdapter
拿到對應(yīng)HandlerAdapter時,這時候開始調(diào)用對應(yīng)的Handler處理業(yè)務(wù)邏輯了(這時候?qū)嶋H上已經(jīng)執(zhí)行完了我們的Controller) 執(zhí)行完成之后返回一個ModeAndView
這時候交給我們的ViewResolver通過視圖名稱查找出對應(yīng)的視圖然后返回
最后,渲染視圖 返回渲染后的視圖 -->響應(yīng)請求
SpringMVC 源碼解析
首先我們查看繼承關(guān)系(關(guān)鍵查看藍(lán)色箭頭路線) 會發(fā)現(xiàn)DispatcherServlet無非就是一個HttpServlet
由此,我們可以去查看Servlet的關(guān)鍵方法:service,doGet,doPost
service@Override
br/>@Override
throws ServletException, IOException {
HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
if (httpMethod == HttpMethod.PATCH || httpMethod == null) {
proce***equest(request, response);
}
else {
super.service(request, response);}
}
1
2
3
4
5
6
7
8
9
10
11
doGet
@Override
br/>}
}
1
2
3
4
5
6
7
8
9
10
11
doGet
@Override
throws ServletException, IOException {
proce***equest(request, response);}
1
2
3
4
5
doPost
@Override
br/>}
1
2
3
4
5
doPost
@Override
throws ServletException, IOException {
proce***equest(request, response);
}
1
2
3
4
5
這里會發(fā)現(xiàn)無論是哪個方法最后都調(diào)用了proce***equest(request, response);我們把焦點放在這個方法上,會發(fā)現(xiàn)一個核心的方法:doService(request, response);然后會發(fā)現(xiàn)這個方法有點不一樣:
protected abstract void doService(HttpServletRequest request, HttpServletResponse response)throws Exception;
它居然是一個抽象方法…這就得回到剛剛的繼承關(guān)系中,找到他的子類了:DispatcherServlet
反正我看到這個方法的實現(xiàn)的時候,腦海里就浮現(xiàn)出4個字:花 里 胡 哨 。代碼太多,就不放在筆記里面了,太占地方了… 為什么這樣說呢? 因為你看完之后會發(fā)現(xiàn)關(guān)鍵在于:doDispatch(request, response);是的,沒看錯,這一行才是關(guān)鍵!
我們把視角切入這個方法 (至于代碼…還是不放進來了… ) 總結(jié)一下:
把要用的變量都定義好:比如我們的ModelAndView以及異常…等等;
下面即將看到的是一個熟悉的陌生人(噢不,關(guān)鍵詞)
processedRequest = checkMultipart(request);
“Multipart” 這個關(guān)鍵詞好像在哪見過??…讓我想想…(漸漸步入了知識盲區(qū)) 哦對!在文件上傳的時候?。銖娤肫饋砹?。。) 是的,其實這行代碼就是判斷當(dāng)前請求是否是一個二進制請求(有沒有帶文件) 當(dāng)然 這里只是提一下,并不是本文的核心內(nèi)容。。。(有時間的小伙伴可以自己去了解一下)
好的,現(xiàn)在回到我們的主題,來看看這個方法:
mappedHandler = getHandler(processedRequest);
看過我們上面流程圖的同學(xué)應(yīng)該會知道他現(xiàn)在在干嘛。 現(xiàn)在來獲取我們的Handler了…從哪獲取呢? 從他的HandlerMapping里面獲取。
問題1:至于這個HandlerMappings 哪里來的呢
這個等下討論 我們先來看看他獲取的代碼:
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
for (HandlerMapping hm : this.handlerMappings) {
if (logger.isTraceEnabled()) {
logger.trace(
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "'");
}
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
我們能看見他是在遍歷一個handlerMappings
問題2:至于這個handlerMapping是什么呢
是兩個我們不認(rèn)識的東西,至于是什么,現(xiàn)在說了也不知道,我們繼續(xù)往下走,可以看見圖片上1188行代碼, 他從這個mapping 里面獲取了一個handler 如果獲取到了 這個方法就走完了, 不然就下一次循環(huán)
問題1解釋:
我們先回到剛剛那個問題,這個HandlerMapping 哪里來的呢。 不多說,上圖:
我們在源碼包的DispatcherServlet.properties文件下會看見, 他定義了圖片里的這些屬性。 重點放在方框內(nèi),第一個屬性,就是我們剛看見的HandlerMappings, 也就是說 HandlerMappings也就是他自己事先定義好的呢。至于第二個屬性,咱們待會兒見~
也就是說SpringMVC自己自帶了2個HandlerMapping 來供我們選擇 至于 為什么要有2個呢? 這時候得啟動項目從斷點的角度來看看了;
我們用2種方式來注冊Controller 分別是:
作為Bean的形式:@Component("/test")
br/>@Component("/test")
br/>@Override
System.out.println("1");
return null;}
}
1
2
3
4
5
6
7
8
以Annotation形式:
@Controller
br/>}
}
1
2
3
4
5
6
7
8
以Annotation形式:
@Controller
br/>@RequestMapping("/test2")
System.out.println("test");
return null;
}
}
1
2
3
4
5
6
7
8
我們先用Bean的方式來跑:
視角走到我們的mappedHandler = getHandler(processedRequest);里面
問題2解釋:
來,跟著箭頭走,我們發(fā)現(xiàn) 我們以Bean的形式注冊的Controller 可以從這個BeanNameUrlHandlerMapping里面獲取到對應(yīng)的Handler ; 這里 我們是不是對于這個HandlerMapping有了懵懂的了解了?
猜想1:
我們來猜一下 如果是以Annotation的形式注冊的Controller的話 就會被第二個HandlerMapping獲取到。 至于對不對 這個問題我們先留著。
我們先讓代碼繼續(xù)走,會發(fā)現(xiàn) Handler返回出來緊接著會執(zhí)行下面這個方法,這個方法我們從流程圖中可以了解到,就是在找一個適配器。
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
問題3:何為適配器?
我們先來看看他這個方法里面干了啥:
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
if (this.handlerAdapters != null) {
for (HandlerAdapter ha : this.handlerAdapters) {
if (logger.isTraceEnabled()) {
logger.trace("Testing handler adapter [" + ha + "]");
}
if (ha.supports(handler)) {
return ha;
}
}
}
throw new ServletException("No adapter for handler [" + handler +
"]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
其實能看見他是從一個handlerAdapters屬性里面遍歷了我們的適配器 這個handlerAdapters哪來的呢? 跟我們的HandlerMappings一樣 在他的配置文件里面有寫,就是我們剛剛所說的 待會兒見的那個東西~ 不多說,上圖:
問題3解釋:
至于什么是適配器,我們結(jié)合Handler來講, 就如我們在最開始的總結(jié)時所說的, 一開始只是找到了Handler 現(xiàn)在要執(zhí)行了,但是有個問題,Handler不止一個, 自然而然對應(yīng)的執(zhí)行方式就不同了, 這時候適配器的概念就出來了:對應(yīng)不同的Handler的執(zhí)行方案。
當(dāng)找到合適的適配器的時候, 基本上就已經(jīng)收尾了,因為后面在做了一些判斷之后(判斷請求類型之類的),就開始執(zhí)行了你的Handler了,上代碼:
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
這個mv就是我們的ModlAndView 其實執(zhí)行完這一行 我們的Controller的邏輯已經(jīng)執(zhí)行完了, 剩下的就是尋找視圖 渲染圖的事情了…
我們這里只是使用了Bean的形式執(zhí)行了一遍流程 假設(shè)使用Annotation呢?
SpringMVC BeanName方式和Annotation方式注冊Controller源碼分析
現(xiàn)在我們來使用Annotation來注冊Controller看看。我們這里只看不同的地方。
猜想1證明:
首先在這個HandlerMappings這里之前的那個就不行了 這里采用了另外一個HandlerMapping 其實也就證明了我們的猜想1
然后就是到了我們的適配器了:
這里我們會看到用的是這個適配器 而我們的Bean方式注冊的Controller 的話 使用的是另外兩個適配器來的,至于有什么區(qū)別呢? 我們來看看他執(zhí)行的時候:
@Override@Nullable
br/>@Nullable
throws Exception {
return handleInternal(request, response, (HandlerMethod) handler);
}
1
2
3
4
5
6
我們的Annotation的形式 是拿到這個handler作為一個HandlerMethod 也就是一個方法對象來執(zhí)行 這時候我們看看Bean是什么樣子的:
@Override@Nullable
br/>@Nullable
throws Exception {
return ((Controller) handler).handleRequest(request, response);
}
1
2
3
4
5
6
由最開始可以看到 我們?nèi)绻訠ean的形式注冊Controller的話 我們的實現(xiàn)一個Controller的接口 在這里 他把我們的handler強制轉(zhuǎn)換為一個Controller來執(zhí)行了。
總結(jié)
其實我們的SpringMVC關(guān)鍵的概念就在于Handler(處理器) 和Adapter(適配器)
通過一個關(guān)鍵的HandlerMappings 找到合適處理你的Controller的Handler 然后再通過HandlerAdapters找到一個合適的HandlerAdapter 來執(zhí)行Handler即Controller里面的邏輯。 最后再返回ModlAndView…
今天就分享到這里了,如果想要繼續(xù)了解spring的同學(xué)可以關(guān)注我的公種號【Java架構(gòu)君】
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
網(wǎng)頁題目:干貨!從上帝視角來看SpringMVC-創(chuàng)新互聯(lián)
當(dāng)前鏈接:http://muchs.cn/article10/pipgo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站排名、服務(wù)器托管、品牌網(wǎng)站設(shè)計、小程序開發(fā)、動態(tài)網(wǎng)站、用戶體驗
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容