Unterschied zwischen Interceptor und Filter in Spring MVC

Ich bin ein bisschen verwirrt über Filterund InterceptorAbsichten.

Wie ich aus Dokumenten verstanden habe, Interceptorwird zwischen Anfragen ausgeführt. Auf der anderen Seite Filterwird vor dem Rendern der Ansicht ausgeführt, aber nachdem der Controller die Antwort gerendert hat.

Wo liegt also der Unterschied zwischen postHandle()Interceptor und doFilter()Filter?

Was ist die beste Vorgehensweise in welchen Anwendungsfällen? In diesem Bild wo arbeitet Filters und Interceptors?

Aus HandlerIntercepterdem Javadoc :

HandlerInterceptorähnelt im Grunde einem Servlet Filter, ermöglicht jedoch im Gegensatz zu letzterem nur eine benutzerdefinierte Vorverarbeitung mit der Option, die Ausführung des Handlers selbst und eine benutzerdefinierte Nachbearbeitung zu verbieten. Filter sind leistungsfähiger, z. B. ermöglichen sie den Austausch der Anforderungs- und Antwortobjekte, die über die Kette weitergegeben werden. Beachten Sie, dass ein Filter in web.xmla HandlerInterceptorim Anwendungskontext konfiguriert wird .

Als grundlegende Richtlinie sind feinkörnige Handler-bezogene Vorverarbeitungsaufgaben Kandidaten für HandlerInterceptorImplementierungen, insbesondere ausgerechnete allgemeine Handler-Code- und Berechtigungsprüfungen. Auf der anderen Seite Filtereignet sich a gut für die Bearbeitung von Anforderungsinhalten und zum Anzeigen von Inhalten, wie z. B. mehrteilige Formulare und GZIP-Komprimierung. Dies zeigt normalerweise, wann der Filter bestimmten Inhaltstypen (z. B. Bildern) oder allen Anforderungen zugeordnet werden muss.

Nachdem dies gesagt wurde:

Wo ist also der Unterschied zwischen Interceptor#postHandle()und Filter#doFilter()?

postHandlewird nach dem Aufruf der Handler-Methode, jedoch vor dem Rendern der Ansicht aufgerufen. Sie können der Ansicht also weitere Modellobjekte hinzufügen, diese jedoch nicht ändern, HttpServletResponseda sie bereits festgeschrieben sind.

doFilterist viel vielseitiger als die postHandle. Sie können die Anforderung oder Antwort ändern und an die Kette übergeben oder sogar die Anforderungsverarbeitung blockieren.

Außerdem haben Sie in preHandleund postHandleMethoden Zugriff auf die HandlerMethod, die die Anforderung verarbeitet hat. Sie können also eine Vor- / Nachbearbeitungslogik basierend auf dem Handler selbst hinzufügen. Sie können beispielsweise eine Logik für Handlermethoden hinzufügen, die einige Anmerkungen enthalten.

Was ist die beste Vorgehensweise in welchen Anwendungsfällen?

Wie im Dokument erwähnt, sind feinkörnige Handler-bezogene Vorverarbeitungsaufgaben Kandidaten für HandlerInterceptorImplementierungen, insbesondere ausgerechnete allgemeine Handler-Code- und Berechtigungsprüfungen. Auf der anderen Seite Filtereignet sich a gut für die Bearbeitung von Anforderungsinhalten und zum Anzeigen von Inhalten, wie z. B. mehrteilige Formulare und GZIP-Komprimierung. Dies zeigt normalerweise, wann der Filter bestimmten Inhaltstypen (z. B. Bildern) oder allen Anforderungen zugeordnet werden muss.

Filter : - Ein Filter, wie der Name schon sagt, ist eine Java-Klasse, die vom Servlet-Container für jede eingehende HTTP-Anforderung und für jede http-Antwort ausgeführt wird. Auf diese Weise können eingehende HTTP-Anforderungen verwaltet werden, bevor sie die Ressource erreichen, z. B. eine JSP-Seite, ein Servlet oder eine einfache statische Seite. Auf die gleiche Weise ist es möglich, ausgehende HTTP-Antworten nach der Ressourcenausführung zu verwalten.

Interceptor : - Spring Interceptors ähneln Servlet-Filtern, verhalten sich jedoch im Spring-Kontext. Sie sind daher leistungsstark, um HTTP-Anforderungen und -Antworten zu verwalten. Sie können jedoch ein komplexeres Verhalten implementieren, da sie auf den gesamten Spring-Kontext zugreifen können.

Ein HandlerInterceptor bietet Ihnen eine feinere Steuerung als ein Filter, da Sie Zugriff auf den eigentlichen Ziel- "Handler" haben. Dies bedeutet, dass die von Ihnen ausgeführten Aktionen je nach der tatsächlichen Ausführung der Anforderung variieren können (während der Servlet-Filter generisch angewendet wird auf alle Anfragen - kann nur die Parameter jeder Anfrage berücksichtigen). Der handlerInterceptor bietet außerdem drei verschiedene Methoden, mit denen Sie das Verhalten vor dem Aufrufen eines Handlers anwenden können, nachdem der Handler abgeschlossen wurde, aber vor dem Rendern der Ansicht (wobei Sie das Rendern der Ansicht möglicherweise sogar ganz umgehen) oder nachdem die Ansicht selbst gerendert wurde. Sie können auch verschiedene Interceptors für verschiedene Gruppen von Handlern einrichten. Die Interceptors werden in der handlerMapping konfiguriert, und es können mehrere handlerMappings vorhanden sein.

Wenn Sie also etwas vollständig Generisches tun müssen (z. B. alle Anforderungen protokollieren), ist ein Filter ausreichend. Wenn das Verhalten jedoch vom Zielhandler abhängt oder Sie etwas zwischen der Anforderungsbearbeitung und dem Rendern der Ansicht tun möchten, dann die HandlerInterceptor bietet diese Flexibilität.

Referenz: http://static.springframework.org/sp...ng-interceptor