1. Filtrar
Al depender del contenedor de servlets, la implementación se basa en devoluciones de llamadas de funciones y puede filtrar casi todas las solicitudes, pero la desventaja es que solo se puede llamar a una instancia de filtro una vez cuando se inicializa el contenedor. El propósito de usar filtros es realizar algunas operaciones de filtrado para obtener los datos que queremos obtener. Los filtros se usan generalmente para verificar el permiso de inicio de sesión, controlar el permiso de acceso a recursos, filtrar palabras confidenciales, convertir codificación de caracteres, etc., para facilitar la reutilización del código. No es necesario realizar operaciones redundantes en cada servlet.
El filtro en Java no es un servlet estándar y no puede manejar solicitudes de usuarios ni generar respuestas para el cliente. Se utiliza principalmente para el preprocesamiento de HttpServletRequest y también se puede utilizar para el posprocesamiento de HttpServletResponse, es una cadena de procesamiento típica. El proceso completo es: Filter preprocesa la solicitud del usuario, luego entrega la solicitud al Servlet para que la procese y genera una respuesta, y finalmente Filter procesa posteriormente la respuesta del servidor. Antes de que HttpServletRequest llegue al Servlet, intercepte el HttpServletRequest del cliente. Verifique HttpServletRequest según sea necesario y también puede modificar el encabezado y los datos de HttpServletRequest. Intercepte HttpServletResponse antes de que la respuesta llegue al cliente. Verifique HttpServletResponse según sea necesario y modifique el encabezado y los datos de HttpServletResponse.
El filtro se inicia cuando se inicia la aplicación web, solo se inicializa una vez y se destruye cuando la aplicación web se detiene.
1. Cargue la instancia del filtro al iniciar el servidor y llame al método init() para inicializar la instancia;
2. Llame solo al método doFilter() para procesar cada solicitud;
3. Al detener el servidor, llame a destroy () método para destruir la instancia.
Proceso de la cadena de procesamiento del filtro:
la solicitud enviada por el navegador se envía primero al primer filtro para el filtrado. Si cumple con las reglas, se libera y se envía al siguiente filtro en la cadena de filtros para el filtrado. El orden de los filtros en la cadena está relacionado con el orden en que están configurados en web.xml, el que se configura primero se ubica al final de la cadena. Cuando la solicitud pasa todos los filtros de la cadena, se puede acceder al archivo de recursos, si no puede pasar, se puede procesar en uno de los filtros intermedios. Configure filtros en web.xml. Se debe tener en cuenta un principio aquí: oyente > filtro > servlet
en el método doFilter(). Antes de chain.doFilter(), generalmente es la operación de filtrado realizada en la solicitud. El código después de la cadena .doFilter es generalmente la operación realizada en la respuesta.
2. El interceptor
depende del marco web, en SpringMVC, depende del marco SpringMVC. La implementación se basa en el mecanismo de reflexión de Java, que es una aplicación de programación orientada a aspectos (AOP). Dado que el interceptor se basa en la llamada del marco web, el interceptor puede llamar a varias dependencias en el contenedor IOC, pero el filtro no, por lo que la inyección de dependencia de Spring se puede utilizar para realizar algunas operaciones comerciales. Al mismo tiempo, un interceptor La instancia está en el ciclo de vida de un controlador. Se puede llamar varias veces dentro de ella. Sin embargo, la desventaja es que solo puede interceptar solicitudes del controlador, pero no puede interceptar otras solicitudes, como el acceso directo a recursos estáticos.
El Interceptor en Spring MVC puede entenderse como una implementación de AOP mediante el marco Spring MVC. En general, las funciones simples son universales y deben procesarse para cada solicitud. Por ejemplo, para determinar si el token no es válido, puede usar HanlderInterceptor de Spring MVC. Para funciones complejas, como el almacenamiento en caché, que requieren un alto grado de personalización, use Spring. aop. En términos generales, la capa de servicio usa más Spring Aop. Cuando la capa de controlador necesita usar solicitud y respuesta, puede usar interceptores.
Las solicitudes de interceptación del interceptor en Spring MVC se implementan a través de HandlerInterceptor. Por lo tanto, el interceptor HandlerInteceptor solo se puede utilizar en el entorno Spring Web MVC. Hay dos formas principales de definir un interceptor en SpringMVC: la primera es implementar la interfaz HandlerInterceptor de Spring u otras clases que implementen la interfaz HandlerInterceptor, como HandlerInterceptorAdapter. La segunda forma es implementar la interfaz WebRequestInterceptor u otras clases que implementen WebRequestInterceptor.
La interfaz HandlerInterceptor define los métodos preHandle, postHandle y afterCompletion:
preHandle (ejecutado antes de ingresar al método Handler): método de devolución de llamada de preprocesamiento para implementar el preprocesamiento del procesador (como la verificación de inicio de sesión), valor de retorno: verdadero significa continuar el proceso (como llamar la siguiente interceptación) interceptor o procesador), falso indica que el proceso está interrumpido (como una falla en la verificación de inicio de sesión) y no se seguirán llamando a otros interceptores o procesadores. En este momento, debemos generar una respuesta mediante respuesta.
postHandle (después de ingresar el método del controlador, antes de regresar a modelAndView): método de devolución de llamada de posprocesamiento para implementar el posprocesamiento del procesador (pero antes de renderizar la vista). En este momento, podemos procesar o modificar los datos del modelo a través de modelAndView ( objetos modelo y vista) La vista se procesa, modelAndView también puede ser nulo.
afterCompletion (ejecute el controlador para completar la ejecución de este método): método de devolución de llamada después de que se procese toda la solicitud, es decir, devolución de llamada cuando se complete la representación de la vista. Este método también se ejecuta solo cuando el valor de retorno del método preHandle del Interceptor correspondiente actual es verdadero. La función principal de este método es realizar trabajos de limpieza de recursos. Por ejemplo, en el monitoreo del rendimiento, podemos registrar la hora de finalización y generar el tiempo de consumo aquí.
3. Oyente
Un oyente es un programa Java ordinario que implementa una interfaz específica. Este programa se utiliza especialmente para monitorear llamadas a métodos o cambios de propiedad de otro objeto Java. Cuando el evento anterior ocurre en el objeto monitoreado, un determinado método del oyente ser llamado inmediatamente implementar.
Principio del oyente Principio
de escucha
1. Hay una fuente de eventos
2. Proporcionar un oyente
3. Registrar un oyente para la fuente del evento
4. Operar la fuente del evento, generar un objeto de evento, pasar el objeto de evento al oyente y ejecutar la escucha correspondiente método del oyente
Los oyentes de servlet
(no se requiere configuración, pero los oyentes aún deben estar registrados)
definen varios tipos de oyentes en la especificación de servlet. Las fuentes de eventos que utilizan para escuchar son tres objetos de dominio: ServletContext, HttpSession y ServletRequest.
Los oyentes de servlet se dividen en tres categorías principales
: 1. Oyentes de creación y destrucción de objetos del dominio de datos
, 2. Oyentes de cambio de atributos y objetos del dominio de datos
, 3. Oyentes de eventos vinculados al estado de un objeto en el dominio HttpSession.
La diferencia entre interceptores y filtros
1. Los interceptores se basan en el mecanismo de reflexión de Java, mientras que los filtros se basan en devoluciones de llamadas de funciones.
2. El interceptor no depende del contenedor de servlet, pero el filtro depende del contenedor de servlet.
3. Los interceptores solo pueden funcionar con solicitudes del Controlador, mientras que los filtros pueden funcionar con casi todas las solicitudes.
4. Los interceptores pueden acceder a objetos en el contexto del controlador y la pila de valores, pero los filtros no.
5. En el ciclo de vida del Controlador, el interceptor se puede llamar varias veces, mientras que el filtro solo se puede llamar una vez cuando se inicializa el contenedor.
6. El interceptor puede obtener cada bean en el contenedor IOC, pero el filtro no. Esto es muy importante: inyectar un servicio en el interceptor puede llamar a la lógica empresarial.
Orden de ejecución: antes del filtrado - antes de la interceptación - Procesamiento de acciones - después de la interceptación - después del filtrado.
Primero, se filtra el contenido enviado por el cliente (por ejemplo, los usuarios que no han iniciado sesión no pueden acceder a las páginas internas); después de
pasar el filtrado, el interceptor verificará la verificación de los datos enviados por el usuario y realizará algunos datos preliminares. Procese y luego envíe los datos procesados a la acción correspondiente;
una vez que el procesamiento de la acción se completa y devuelve, el interceptor también puede realizar otros procesos y luego regresar a las operaciones posteriores del filtro.