Sono un po 'confuso su Filtere sugli Interceptorscopi.
Come ho capito dai documenti, Interceptorviene eseguito tra le richieste. D'altra parte Filterviene eseguito prima del rendering della vista, ma dopo il rendering della risposta del controller.
Allora, qual è la differenza tra postHandle()in Interceptor e doFilter()in Filter?
Qual è la migliore pratica in quali casi d'uso dovrebbe essere utilizzato? In questo quadro in cui le opere Filterdi s e Interceptors?
Risposte:
Da HandlerIntercepter's javadoc :
HandlerInterceptorè sostanzialmente simile a un servletFilter, ma a differenza di quest'ultimo consente solo la pre-elaborazione personalizzata con la possibilità di vietare l'esecuzione del gestore stesso e la post-elaborazione personalizzata. I filtri sono più potenti, ad esempio consentono di scambiare gli oggetti richiesta e risposta che vengono trasmessi lungo la catena. Si noti che un filtro viene configurato inweb.xml, aHandlerInterceptornel contesto dell'applicazione.Come linea guida di base, le attività di pre-elaborazione relative al gestore a grana fine sono candidati per le
HandlerInterceptorimplementazioni, in particolare il codice del gestore comune scomposto e i controlli di autorizzazione. D'altra parte, aFilterè adatto per la gestione del contenuto della richiesta e della visualizzazione, come i moduli multipart e la compressione GZIP. Questo in genere mostra quando è necessario mappare il filtro a determinati tipi di contenuto (ad es. Immagini) oa tutte le richieste.
Detto questo:
Allora dov'è la differenza tra
Interceptor#postHandle()eFilter#doFilter()?
postHandleverrà chiamato dopo l'invocazione del metodo del gestore ma prima che la vista venga renderizzata. Quindi, è possibile aggiungere altri oggetti del modello alla vista, ma si può non cambiare il HttpServletResponsedal momento che è già impegnata.
doFilterè molto più versatile del postHandle. È possibile modificare la richiesta o la risposta e passarla alla catena o addirittura bloccare l'elaborazione della richiesta.
Inoltre, in preHandlee postHandlemetodi, hai accesso a quello HandlerMethodche ha elaborato la richiesta. Quindi, puoi aggiungere la logica di pre / post-elaborazione basata sul gestore stesso. Ad esempio, è possibile aggiungere una logica per i metodi del gestore che hanno alcune annotazioni.
Qual è la migliore pratica in quali casi d'uso dovrebbe essere utilizzato?
Come ha detto il documento, le attività di pre-elaborazione relative al gestore a grana fine sono candidati per le HandlerInterceptorimplementazioni, in particolare il codice del gestore comune scomposto e i controlli di autorizzazione. D'altra parte, a Filterè adatto per la gestione del contenuto della richiesta e della visualizzazione, come i moduli multipart e la compressione GZIP. Questo in genere mostra quando è necessario mappare il filtro a determinati tipi di contenuto (ad es. Immagini) o a tutte le richieste.
HandlerIntercepterè un concetto specifico di Spring. Per registrare un filtro servlet, è possibile registrarlo utilizzando il vecchio web.xml(Servlet 2.5 e versioni precedenti) o il nuovo approccio programmatico (Servlet 3+). Poiché HandlerIntercepterè solo un'astrazione primaverile, dovresti registrarti nel contesto della primavera
WebApplicationcui è parte singola per dispatcher, quindi servlet e filtro sono entrambi associati al contesto, è una buona pratica associare l'interceptor e il filtro con rootContextquindi se u hv più dispatcher tutti possono condividere lo stesso.
Filtro : - Un filtro come suggerisce il nome è una classe Java eseguita dal contenitore servlet per ogni richiesta HTTP in entrata e per ogni risposta http. In questo modo è possibile gestire le richieste HTTP in arrivo prima che raggiungano la risorsa, come una pagina JSP, un servlet o una semplice pagina statica; allo stesso modo è possibile gestire la risposta HTTP in uscita dopo l'esecuzione della risorsa.
Interceptor : - Gli Spring Interceptor sono simili ai filtri servlet ma agiscono nel contesto Spring, quindi sono molti potenti per gestire richieste e risposte HTTP ma possono implementare comportamenti più sofisticati perché possono accedere a tutto il contesto Spring.
Un HandlerInterceptor ti offre un controllo più dettagliato di un filtro, perché hai accesso al "gestore" di destinazione effettivo - questo significa che qualunque azione tu esegua può variare a seconda di ciò che la richiesta sta effettivamente facendo (mentre il filtro servlet viene applicato genericamente a tutte le richieste - solo in grado di tenere conto dei parametri di ogni richiesta). HandlerInterceptor fornisce anche 3 diversi metodi, in modo che tu possa applicare il comportamento prima di chiamare un gestore, dopo che il gestore è stato completato ma prima del rendering della vista (dove puoi anche ignorare del tutto il rendering della vista), o dopo che la vista stessa è stata renderizzata. Inoltre, puoi configurare diversi intercettori per diversi gruppi di gestori: gli intercettori sono configurati su handlerMapping e potrebbero esserci più handlerMapping.
Pertanto, se hai bisogno di fare qualcosa di completamente generico (ad es. Registrare tutte le richieste), allora un filtro è sufficiente - ma se il comportamento dipende dal gestore di destinazione o vuoi fare qualcosa tra la gestione delle richieste e il rendering della vista, allora il HandlerInterceptor fornisce questa flessibilità.
Riferimento: http://static.springframework.org/sp...ng-interceptor