Introduction
When reviewing Spring's AOP these days, I was a little curious about the relationship between filters, interceptors, and AOP, so I kept records for backup. When implementing some common logic, many functions can be implemented through filters, interceptors, and AOP, but different methods have different efficiencies. For specific differences, see the description below.
Basic logic of front-end interaction
filter
The filter intercepts the URL
The custom filter (Filter) in Spring generally has only one method, and the return value is void. When the request reaches the web container, it will detect whether the current request address is configured with a filter, and if there is, call the method of the filter (there may be more Filters), and then call the real business logic, so far the filter task is completed. The filter does not define before and after the business logic is executed, it is only executed when the request arrives.
Special note: the input parameters of the filter method are request, response, and FilterChain, where FilterChain is the filter chain, which is relatively simple to use, while request and response are related to the request process, so request parameters can be filtered and modified, and FilterChain filters After the chain is executed and the business process is completed, it will return to the filter. At this time, the requested return data can also be processed.
Interceptor
The interceptor intercepts the URL
The interceptor has three methods, which are more detailed than the filter, including before and after the intercepted logic is executed. The interceptor in Spring has three methods: preHandle, postHandle, and afterCompletion. Respectively expressed as follows
public boolean preHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o) indicates the custom processing before execution of the method corresponding to the intercepted URL
public void postHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, ModelAndView modelAndView) means that modelAndView has not been rendered at this time, and the method corresponding to the intercepted URL is the custom processing after execution.
public void afterCompletion(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, Exception e) means that the modelAndView has been rendered at this time, and the interceptor's custom processing is executed.
AOP (Aspect Oriented)
Aspect-oriented interception is the metadata of the class (package, class, method name, parameter, etc.)
Compared with interceptors, they are more detailed and very flexible. Interceptors can only intercept URLs, while AOP can implement more complex business logic for specific codes. Refer to other blogs for specific types.
Three usage scenarios
The functions of the three are similar, but each has its own advantages. From the filter-"Interceptor -" aspect, the interception rules are becoming more and more detailed, and the order of execution is filter, interceptor, and aspect in order. In general, the earlier the data is filtered, the less impact on the performance of the service. Therefore, when we write relatively common code, we give priority to filters, then interceptors, and finally aop. For example, permission verification. Under normal circumstances, all requests need to be logged in verification. At this time, you should use filters to verify at the top level; log records, generally logs will only log some of the logic, and it involves The log records before and after the business logic is completed, so the filter cannot be used to divide the modules in detail. At this time, the interceptor should be considered. However, the interceptor is also based on the URL to do rule matching, so it is relatively not detailed enough, so we will consider the use of AOP implementation , AOP can intercept the method level of the code, which is very suitable for the logging function.