HandlerInterceptor介面有一個引數，這Object handler意味著實作代碼必須對處理程式物件進行型別檢查才能使用它，并根據需要進行轉換。
我發現的代碼片段似乎假設處理程式始終是一個HandlerMethod物件，如果不是這種情況，則回傳 true，但我想了解為什么這似乎是實作健壯實作的常見實作。
實作此介面的標準方法似乎是：
import org.springframework.web.method.HandlerMethod;
import org.springframework.web.servlet.HandlerInterceptor;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MyInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
if (handler instanceof HandlerMethod) {
// ...
return x; // whether or not to proceed with execution
}
return true; // fallback value in case handler wasn't a HandlerMethod
}
}
Spring javadoc似乎忽略了介面中有一個Object型別的事實，這對我理解這個介面非常沒有幫助。
一些可能有助于我理解該介面應該如何實作的問題：
true如果我們得到一個不是我們期望的物件的處理程式，為什么是合理的默認值？- 哪些型別可以作為
HandlerInterceptor它的handler引數？ - 如果有的話，在什么情況下可能
handler是不同的型別？ - 為什么它是一個
Object，而不是一個HandlerMethod，引數？
uj5u.com熱心網友回復：
基本上，handler引數可以是HandlerAdapter存在 a 的任何型別。最常用的是RequestMappingHandlerAdapter使用HandlerMethod.
但它可以是一個常規類、一個 servlet，甚至是一個函式（當使用函式式方法時）。Spring Web Services 也有一個實作以及 Spring Integration。
Spring 本身將支持以下開箱即用
HandlerMethodHandlerFunctionControllerServletHttpRequestHandlerWsdlDefinition（春季網路服務）XsdDefinition（春季網路服務）
所以不，它并不總是一個HandlerMethod，但它會適用于大多數用戶。
uj5u.com熱心網友回復：
這是 javadoc 的內容HandlerInterceptor#preHandle()：
處理程式執行之前的攔截點。在 HandlerMapping 確定適當的處理程式物件之后，但在HandlerAdapter 呼叫處理程式之前呼叫。
DispatcherServlet 處理執行鏈中的處理程式，該處理程式由任意數量的攔截器組成，處理程式本身位于最后。使用此方法，每個攔截器都可以決定中止執行鏈，通常是發送 HTTP 錯誤或撰寫自定義回應。
這意味著攔截器根本不應該接觸handler，所以他們不需要知道任何關于它的事情。他們唯一的作業是決定是否進一步通過請求。
順便說一句，沒有一個標準HandlerInterceptor#preHandle()實作 org.springframework.web.servlet.*試圖分析真實的handler引數型別并基于它做任何邏輯。
為什么它是物件，而不是 HandlerMethod 引數？
從org.springframework.web.servlet.HandlerMapping#getHandler()javadoc：
回傳此請求的處理程式和任何攔截器。可以根據請求 URL、會話狀態或實作類選擇的任何因素進行選擇。
回傳的 HandlerExecutionChain 包含一個處理程式物件，而不是一個標記介面，因此處理程式不受任何約束。例如，可以撰寫 HandlerAdapter 以允許使用另一個框架的處理程式物件。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/472563.html