Różnica między Interceptorem a filtrem w Spring MVC

Jestem trochę zdezorientowany Filteri Interceptorcele.

Jak zrozumiałem z dokumentów, Interceptorjest uruchamiany między żądaniami. Z drugiej strony Filterjest uruchamiany przed renderowaniem widoku, ale po wyrenderowaniu odpowiedzi przez kontroler.

Więc gdzie jest różnica między postHandle()w Interceptorze i doFilter()w filtrze?

Jaka jest najlepsza praktyka, w jakich przypadkach należy jej używać? W tym obrazie, gdzie prace Filters oraz Interceptors?

Z HandlerIntercepter„s javadoc :

HandlerInterceptorjest zasadniczo podobny do serwletu Filter, ale w przeciwieństwie do tego drugiego, umożliwia po prostu niestandardowe przetwarzanie wstępne z opcją zakazania wykonywania samego modułu obsługi i niestandardowego przetwarzania końcowego. Filtry mają większe możliwości, na przykład umożliwiają wymianę obiektów żądań i odpowiedzi, które są przekazywane w łańcuchu. Zauważ, że filtr jest konfigurowany w web.xml, a HandlerInterceptorw kontekście aplikacji.

Zgodnie z podstawową wytyczną, szczegółowe zadania przetwarzania wstępnego związane z procedurą obsługi są kandydatami do HandlerInterceptorimplementacji, w szczególności z uwzględnieniem wspólnego kodu procedury obsługi i kontroli autoryzacji. Z drugiej strony, a Filterjest dobrze dostosowany do treści żądań i obsługi treści, takich jak formularze wieloczęściowe i kompresja GZIP. Zwykle pojawia się, gdy trzeba odwzorować filtr na określone typy treści (np. Obrazy) lub na wszystkie żądania.

Biorąc to pod uwagę:

Więc gdzie jest różnica między Interceptor#postHandle()i Filter#doFilter()?

postHandlezostanie wywołana po wywołaniu metody obsługi, ale przed renderowaniem widoku. Tak, można dodać więcej obiektów modelu do widoku, ale może nie zmienić HttpServletResponse, ponieważ już popełnione.

doFilterjest znacznie bardziej wszechstronny niż postHandle. Możesz zmienić żądanie lub odpowiedź i przekazać je do łańcucha lub nawet zablokować przetwarzanie żądania.

Ponadto w programie preHandlei postHandleMethods masz dostęp do tego, HandlerMethodktóry przetworzył żądanie. Możesz więc dodać logikę przetwarzania wstępnego / końcowego w oparciu o samą procedurę obsługi. Na przykład można dodać logikę dla metod obsługi, które mają pewne adnotacje.

Jaka jest najlepsza praktyka, w jakich przypadkach należy jej używać?

Jak wspomniano w dokumencie, drobnoziarniste zadania przetwarzania wstępnego związane z obsługą są kandydatami do HandlerInterceptorimplementacji, w szczególności z uwzględnieniem wspólnego kodu modułu obsługi i kontroli autoryzacji. Z drugiej strony, a Filterjest dobrze dostosowany do treści żądań i obsługi treści, takich jak formularze wieloczęściowe i kompresja GZIP. Zwykle pojawia się, gdy trzeba odwzorować filtr na określone typy treści (np. Obrazy) lub na wszystkie żądania.

Filtr : - Filtr, jak sugeruje nazwa, to klasa Java wykonywana przez kontener serwletów dla każdego przychodzącego żądania HTTP i dla każdej odpowiedzi http. W ten sposób możliwe jest zarządzanie przychodzącymi żądaniami HTTP, zanim dotrą one do zasobu, takiego jak strona JSP, serwlet lub prosta strona statyczna; w ten sam sposób można zarządzać odpowiedzią wychodzącą HTTP po wykonaniu zasobu.

Interceptor : - Spring Interceptors są podobne do Servlet Filters, ale działają w kontekście Spring Context, więc mają wiele możliwości zarządzania żądaniami i odpowiedziami HTTP, ale mogą implementować bardziej wyrafinowane zachowanie, ponieważ mają dostęp do całego kontekstu Spring.

HandlerInterceptor daje ci bardziej szczegółową kontrolę niż filtr, ponieważ masz dostęp do faktycznej docelowej "obsługi" - oznacza to, że każda czynność, którą wykonujesz, może się różnić w zależności od tego, co faktycznie robi żądanie (podczas gdy filtr serwletu jest stosowany ogólnie do wszystkich żądań - tylko możliwość uwzględnienia parametrów każdego żądania). Procedura handlerInterceptor zapewnia również 3 różne metody, dzięki czemu można zastosować zachowanie przed wywołaniem procedury obsługi, po zakończeniu procedury obsługi, ale przed renderowaniem widoku (gdzie można nawet całkowicie pominąć renderowanie widoku) lub po wyrenderowaniu samego widoku. Możesz także skonfigurować różne przechwytywacze dla różnych grup programów obsługi - przechwytywacze są skonfigurowane w module handlerMapping i może istnieć wiele funkcji handlerMappings.

Dlatego jeśli musisz zrobić coś zupełnie ogólnego (np. Logować wszystkie żądania), filtr jest wystarczający - ale jeśli zachowanie zależy od docelowej obsługi lub chcesz zrobić coś między obsługą żądania a renderowaniem widoku, wtedy HandlerInterceptor zapewnia taką elastyczność.

Źródła: http://static.springframework.org/sp...ng-interceptor