干貨！從上帝視角來看SpringMVC

SpringMVC核心流程圖

簡(jiǎn)單總結(jié)

創(chuàng)新互聯(lián)建站總部坐落于成都市區(qū)，致力網(wǎng)站建設(shè)服務(wù)有成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷策劃、網(wǎng)頁設(shè)計(jì)、網(wǎng)站維護(hù)、公眾號(hào)搭建、微信小程序、軟件開發(fā)等為企業(yè)提供一整套的信息化建設(shè)解決方案。創(chuàng)造真正意義上的網(wǎng)站建設(shè)，為互聯(lián)網(wǎng)品牌在互動(dòng)行銷領(lǐng)域創(chuàng)造價(jià)值而不懈努力！

首先請(qǐng)求進(jìn)入DispatcherServlet 由DispatcherServlet 從HandlerMappings中提取對(duì)應(yīng)的Handler

此時(shí)只是獲取到了對(duì)應(yīng)的Handle，然后得去尋找對(duì)應(yīng)的適配器，即：HandlerAdapter

拿到對(duì)應(yīng)HandlerAdapter時(shí)，這時(shí)候開始調(diào)用對(duì)應(yīng)的Handler處理業(yè)務(wù)邏輯了（這時(shí)候?qū)嶋H上已經(jīng)執(zhí)行完了我們的Controller） 執(zhí)行完成之后返回一個(gè)ModeAndView

這時(shí)候交給我們的ViewResolver通過視圖名稱查找出對(duì)應(yīng)的視圖然后返回

最后，渲染視圖 返回渲染后的視圖 -->響應(yīng)請(qǐng)求

SpringMVC 源碼解析

首先我們查看繼承關(guān)系(關(guān)鍵查看藍(lán)色箭頭路線) 會(huì)發(fā)現(xiàn)DispatcherServlet無非就是一個(gè)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
這里會(huì)發(fā)現(xiàn)無論是哪個(gè)方法最后都調(diào)用了proce***equest(request, response);我們把焦點(diǎn)放在這個(gè)方法上，會(huì)發(fā)現(xiàn)一個(gè)核心的方法：doService(request, response);然后會(huì)發(fā)現(xiàn)這個(gè)方法有點(diǎn)不一樣:

protected abstract void doService(HttpServletRequest request, HttpServletResponse response)throws Exception;

它居然是一個(gè)抽象方法…這就得回到剛剛的繼承關(guān)系中，找到他的子類了：DispatcherServlet

反正我看到這個(gè)方法的實(shí)現(xiàn)的時(shí)候，腦海里就浮現(xiàn)出4個(gè)字：花 里 胡 哨 。代碼太多，就不放在筆記里面了，太占地方了… 為什么這樣說呢？ 因?yàn)槟憧赐曛髸?huì)發(fā)現(xiàn)關(guān)鍵在于：doDispatch(request, response);是的，沒看錯(cuò)，這一行才是關(guān)鍵！

我們把視角切入這個(gè)方法 (至于代碼…還是不放進(jìn)來了… ) 總結(jié)一下：

把要用的變量都定義好:比如我們的ModelAndView以及異?！鹊?

下面即將看到的是一個(gè)熟悉的陌生人(噢不，關(guān)鍵詞)

processedRequest = checkMultipart(request);

“Multipart” 這個(gè)關(guān)鍵詞好像在哪見過？？…讓我想想…（漸漸步入了知識(shí)盲區(qū)） 哦對(duì)！在文件上傳的時(shí)候！（勉強(qiáng)想起來了。。） 是的，其實(shí)這行代碼就是判斷當(dāng)前請(qǐng)求是否是一個(gè)二進(jìn)制請(qǐng)求（有沒有帶文件） 當(dāng)然 這里只是提一下，并不是本文的核心內(nèi)容。。。(有時(shí)間的小伙伴可以自己去了解一下)

好的，現(xiàn)在回到我們的主題,來看看這個(gè)方法：

mappedHandler = getHandler(processedRequest);

看過我們上面流程圖的同學(xué)應(yīng)該會(huì)知道他現(xiàn)在在干嘛。 現(xiàn)在來獲取我們的Handler了…從哪獲取呢？ 從他的HandlerMapping里面獲取。

問題1：至于這個(gè)HandlerMappings 哪里來的呢

這個(gè)等下討論 我們先來看看他獲取的代碼:

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
我們能看見他是在遍歷一個(gè)handlerMappings

問題2：至于這個(gè)handlerMapping是什么呢

是兩個(gè)我們不認(rèn)識(shí)的東西，至于是什么，現(xiàn)在說了也不知道，我們繼續(xù)往下走，可以看見圖片上1188行代碼， 他從這個(gè)mapping 里面獲取了一個(gè)handler 如果獲取到了 這個(gè)方法就走完了， 不然就下一次循環(huán)

問題1解釋:

我們先回到剛剛那個(gè)問題，這個(gè)HandlerMapping 哪里來的呢。 不多說，上圖：

我們?cè)谠创a包的DispatcherServlet.properties文件下會(huì)看見， 他定義了圖片里的這些屬性。 重點(diǎn)放在方框內(nèi)，第一個(gè)屬性，就是我們剛看見的HandlerMappings， 也就是說 HandlerMappings也就是他自己事先定義好的呢。至于第二個(gè)屬性，咱們待會(huì)兒見~

也就是說SpringMVC自己自帶了2個(gè)HandlerMapping 來供我們選擇 至于 為什么要有2個(gè)呢？ 這時(shí)候得啟動(dòng)項(xiàng)目從斷點(diǎn)的角度來看看了;

我們用2種方式來注冊(cè)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的形式注冊(cè)的Controller 可以從這個(gè)BeanNameUrlHandlerMapping里面獲取到對(duì)應(yīng)的Handler ; 這里 我們是不是對(duì)于這個(gè)HandlerMapping有了懵懂的了解了？

猜想1：

我們來猜一下 如果是以Annotation的形式注冊(cè)的Controller的話 就會(huì)被第二個(gè)HandlerMapping獲取到。 至于對(duì)不對(duì) 這個(gè)問題我們先留著。

我們先讓代碼繼續(xù)走，會(huì)發(fā)現(xiàn) Handler返回出來緊接著會(huì)執(zhí)行下面這個(gè)方法，這個(gè)方法我們從流程圖中可以了解到，就是在找一個(gè)適配器。

HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

問題3：何為適配器？

我們先來看看他這個(gè)方法里面干了啥：

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
其實(shí)能看見他是從一個(gè)handlerAdapters屬性里面遍歷了我們的適配器 這個(gè)handlerAdapters哪來的呢？ 跟我們的HandlerMappings一樣 在他的配置文件里面有寫，就是我們剛剛所說的 待會(huì)兒見的那個(gè)東西~ 不多說，上圖：

問題3解釋：

至于什么是適配器，我們結(jié)合Handler來講， 就如我們?cè)谧铋_始的總結(jié)時(shí)所說的， 一開始只是找到了Handler 現(xiàn)在要執(zhí)行了，但是有個(gè)問題，Handler不止一個(gè)， 自然而然對(duì)應(yīng)的執(zhí)行方式就不同了， 這時(shí)候適配器的概念就出來了：對(duì)應(yīng)不同的Handler的執(zhí)行方案。

當(dāng)找到合適的適配器的時(shí)候， 基本上就已經(jīng)收尾了，因?yàn)楹竺嬖谧隽艘恍┡袛嘀螅ㄅ袛嗾?qǐng)求類型之類的），就開始執(zhí)行了你的Handler了，上代碼：

mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

這個(gè)mv就是我們的ModlAndView 其實(shí)執(zhí)行完這一行 我們的Controller的邏輯已經(jīng)執(zhí)行完了， 剩下的就是尋找視圖 渲染圖的事情了…

我們這里只是使用了Bean的形式執(zhí)行了一遍流程 假設(shè)使用Annotation呢？

SpringMVC BeanName方式和Annotation方式注冊(cè)Controller源碼分析

現(xiàn)在我們來使用Annotation來注冊(cè)Controller看看。我們這里只看不同的地方。

猜想1證明：

首先在這個(gè)HandlerMappings這里之前的那個(gè)就不行了 這里采用了另外一個(gè)HandlerMapping 其實(shí)也就證明了我們的猜想1

然后就是到了我們的適配器了：

這里我們會(huì)看到用的是這個(gè)適配器 而我們的Bean方式注冊(cè)的Controller 的話 使用的是另外兩個(gè)適配器來的，至于有什么區(qū)別呢？ 我們來看看他執(zhí)行的時(shí)候:

@Override@Nullable
br/>@Nullable
throws Exception {
return handleInternal(request, response, (HandlerMethod) handler);
}
1
2
3
4
5
6
我們的Annotation的形式 是拿到這個(gè)handler作為一個(gè)HandlerMethod 也就是一個(gè)方法對(duì)象來執(zhí)行 這時(shí)候我們看看Bean是什么樣子的：

@Override@Nullable
br/>@Nullable
throws Exception {
return ((Controller) handler).handleRequest(request, response);
}
1
2
3
4
5
6
由最開始可以看到 我們?nèi)绻訠ean的形式注冊(cè)Controller的話 我們的實(shí)現(xiàn)一個(gè)Controller的接口 在這里 他把我們的handler強(qiáng)制轉(zhuǎn)換為一個(gè)Controller來執(zhí)行了。

總結(jié)

其實(shí)我們的SpringMVC關(guān)鍵的概念就在于Handler（處理器） 和Adapter(適配器)

通過一個(gè)關(guān)鍵的HandlerMappings 找到合適處理你的Controller的Handler 然后再通過HandlerAdapters找到一個(gè)合適的HandlerAdapter 來執(zhí)行Handler即Controller里面的邏輯。 最后再返回ModlAndView…

今天就分享到這里了，如果想要繼續(xù)了解spring的同學(xué)可以關(guān)注我的公種號(hào)【Java架構(gòu)君】

本文標(biāo)題：干貨！從上帝視角來看SpringMVC
文章位置：http://muchs.cn/article28/pipjjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、ChatGPT、標(biāo)簽優(yōu)化、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)