Manual de práctica de Java Xiaobai-Fase 5-SpringMVC Framework (día03) -SpringMVC Resumen

Tabla de contenido

SpringMVC

Aplicación de anotación @Controller

Aplicación de anotación @ RequestMapping (procesando la anotación de la asignación de direcciones de solicitud)

El método de solicitud está limitado al tipo POST:

@RequestMapping maneja varios métodos de HTTP 

Tipo de método solicitado

@RequestMapping atajo 

@RequestMapping para manejar múltiples URI 

Utilice @RequestMapping para procesar los parámetros de la solicitud

@RequestMapping con @RequestParam 

Condiciones de uso

@ResponseCuerpo

Interceptador

El papel de los interceptores

Interfaz de interceptor

Uso de interceptores

La diferencia entre interceptor y filtro

lo mismo

la diferencia

Condiciones de uso

Solución confusa china

Resumen de la etapa SpringMVC


SpringMVC

Aplicación de anotación @Controller

Se recomienda utilizar la anotación @Controller para declarar el componente del controlador, lo que puede hacer que la definición del controlador sea más flexible, sin implementar la interfaz del controlador, y el método de procesamiento de solicitudes también se puede definir de manera flexible.

@Controller
public class HelloController{
    public String execute() throws Exception {
    return "hello";
    }
}


Aplicación de anotación @ RequestMapping (procesando la anotación de la asignación de direcciones de solicitud)

En el controlador, agregue una @RequestMappinganotación antes del método de procesamiento de la solicitud , puede configurar la relación de mapeo entre la ruta de la solicitud y el método de procesamiento de la solicitud.

RequestMapping es una anotación que se usa para procesar la asignación de direcciones de solicitud, que se puede usar en clases o métodos. Usado en clases, significa que todos los métodos de la clase que responden a solicitudes usan esta dirección como ruta principal.

En el @RequestMappingcódigo fuente anotado:

/**
 * The primary mapping expressed by this annotation.
 * <p>This is an alias for {@link #path}. For example,
 * {@code @RequestMapping("/foo")} is equivalent to
 * {@code @RequestMapping(path="/foo")}.
 * <p><b>Supported at the type level as well as at the method level!</b>
 * When used at the type level, all method-level mappings inherit
 * this primary mapping, narrowing it for a specific handler method.
 * <p><strong>NOTE</strong>: A handler method that is not mapped to any path
 * explicitly is effectively mapped to an empty path.
 */
@AliasFor("path")
String[] value() default {};

Dado que valuees el atributo predeterminado, lo que normalmente usa es en @RequestMapping("reg.do")realidad valueel valor de este atributo.

Su tipo de datos es String[], por lo que al configurar, ¡puede configurar múltiples rutas al mismo tiempo! P.ej:

// 【显示注册页面】
@RequestMapping({"reg.do", "register.do"})
public String reg() {
    System.out.println("UserController.reg()");
    return "register";
}

El método puede ser ejecutado por tanto reg.doy register.dotanto reg(), y el código del método no ha cambiado. El efecto final es que ambos caminos pueden abrir la misma página!

En el código fuente, hay:

/**
 * The path mapping URIs (e.g. {@code "/profile"}).
 * <p>Ant-style path patterns are also supported (e.g. {@code "/profile/**"}).
 * At the method level, relative paths (e.g. {@code "edit"}) are supported
 * within the primary mapping expressed at the type level.
 * Path mapping URIs may contain placeholders (e.g. <code>"/${profile_path}"</code>).
 * <p><b>Supported at the type level as well as at the method level!</b>
 * When used at the type level, all method-level mappings inherit
 * this primary mapping, narrowing it for a specific handler method.
 * <p><strong>NOTE</strong>: A handler method that is not mapped to any path
 * explicitly is effectively mapped to an empty path.
 * @since 4.2
 */
@AliasFor("value")
String[] path() default {};

Combinando las 2 piezas de código fuente anteriores, puede ver valueque los pathatributos son exactamente los mismos. Si necesita especificar explícitamente el nombre del atributo, utilícelo pathpara expresar mejor la semántica. ¡El nombre del atributo se agregó a partir de la versión 4.2!

También en el código fuente:

/**
 * The HTTP request methods to map to, narrowing the primary mapping:
 * GET, POST, HEAD, OPTIONS, PUT, PATCH, DELETE, TRACE.
 * <p><b>Supported at the type level as well as at the method level!</b>
 * When used at the type level, all method-level mappings inherit
 * this HTTP method restriction (i.e. the type-level restriction
 * gets checked before the handler method is even resolved).
 */
RequestMethod[] method() default {};

Al utilizar la descripción del código fuente anterior @RequestMapping, puede configurar la methodpropiedad nombrada , el tipo de valor de la propiedad es RequestMethod[]tipo y el valor predeterminado es ninguno.

La función de este atributo es "configurar el método de solicitud HTTP mapeado". Si este atributo no está configurado, significa que "se puede acceder a la ruta a través de cualquier método de solicitud". Si este atributo se configura explícitamente, solo se permite el método de solicitud correspondiente al valor de configuración y no se permitirá el método de solicitud sin el valor configurado.

El método de solicitud está limitado al tipo POST:

@RequestMapping(value="handle_reg.do", method=RequestMethod.POST)

Si aún intenta utilizar GET u otros métodos de solicitud no permitidos, se producirá un error 405:

HTTP Status 405 – Method Not Allowed

Y va acompañado de información rápida específica:

Request method 'GET' not supported

@RequestMapping maneja varios métodos de HTTP 

Tipo de método solicitado

La anotación @RequestMapping de Spring MVC puede manejar métodos de solicitud HTTP, como GET, PUT, POST, DELETE y PATCH. 

Todas las solicitudes serán de tipo HTTP GET por defecto. 

Para asignar una solicitud a un método HTTP específico, debe usar el método en @RequestMapping para declarar el tipo de método utilizado por la solicitud HTTP, como se muestra a continuación: 

@RestController  
@RequestMapping("/home")  
public class IndexController {  
    @RequestMapping(method = RequestMethod.GET)  
    String get() {  
        return "Hello from get";  
    }  
    @RequestMapping(method = RequestMethod.DELETE)  
    String delete() {  
        return "Hello from delete";  
    }  
    @RequestMapping(method = RequestMethod.POST)  
    String post() {  
        return "Hello from post";  
    }  
    @RequestMapping(method = RequestMethod.PUT)  
    String put() {  
        return "Hello from put";  
    }  
    @RequestMapping(method = RequestMethod.PATCH)  
    String patch() {  
        return "Hello from patch";  
    }  
}  

método: especifique el tipo de método de la solicitud, dividido en GET, POST, PUT, DELETE, etc .;

Dado que methodel tipo de valor del atributo es RequestMethod[], se puede configurar para permitir múltiples métodos de solicitud, por ejemplo:

@RequestMapping(path="login.do", method={RequestMethod.GET, RequestMethod.POST})

@RequestMapping atajo 


Spring 4.3 introdujo una variante de anotación a nivel de método, también conocida como anotación combinada de @RequestMapping. Las anotaciones combinadas pueden expresar mejor la semántica del método anotado. Su función es encapsular @RequestMapping, y se han convertido en el método estándar para definir puntos finales. 

Por ejemplo, @GetMapping es una anotación compuesta, que actúa como un atajo para @RequestMapping (método = RequestMethod.GET). 
Las variantes de anotación a nivel de método son las siguientes: 

  • @GetMapping
  • @PostMapping
  • @PutMapping
  • @DeleteMapping
  • @PatchMapping

Si necesita limitar el método de solicitud a uno fijo, ¡también puede usar una anotación simplificada! Por ejemplo, al usar @PostMappinganotaciones, puede limitar el método de solicitud para POSTescribir. Al usar, solo necesita configurar la ruta de la solicitud, por ejemplo:

/ @RequestMapping(value="handle_reg.do", method=RequestMethod.POST)
@PostMapping("handle_reg.do")

En @PostMappingel código fuente de la anotación, la declaración sobre la anotación es:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@RequestMapping(method = RequestMethod.POST)
public @interface PostMapping {
}

En una declaración antes de la anotación agregada @RequestMapping(method = RequestMethod.POST)para indicar la @PostMappinganotación actual con una @RequestMappingfunción de las características y la forma en que la solicitud se ha restringido al POST!

Además, hay @GetMapping, @PutMapping, @DeleteMapping, @PatchMapping, cada uno correspondiente a un tipo de un modo de petición!

@RequestMapping para manejar múltiples URI 

Puede asignar varias solicitudes a un método, simplemente agregue una anotación @RequestMapping con una lista de valores de ruta de solicitud.

@RestController  
@RequestMapping("/home")  
public class IndexController {  
  
    @RequestMapping(value = {  
        "",  
        "/page",  
        "page*",  
        "view/*,**/msg"  
    })  
    String indexMultipleMapping() {  
        return "Hello from index multiple mapping.";  
    }  
}  

Como puede ver en este código, @RequestMapping admite comodines y rutas de estilo ANT. En el código anterior, indexMultipleMapping () procesará las siguientes URL:  


localhost:8080/home
localhost:8080/home/
localhost:8080/home/page
localhost:8080/home/pageabc
localhost:8080/home/view/
localhost:8080/home/view/view

Utilice @RequestMapping para procesar los parámetros de la solicitud

@RequestMapping con @RequestParam 

La anotación @RequestParam se usa junto con @RequestMapping para vincular los parámetros de la solicitud con los parámetros del método de procesamiento. 

La anotación @RequestParam puede tener un valor o ningún valor cuando se usa. Este valor especifica el parámetro de solicitud que debe asignarse al parámetro del método de procesamiento, el código es el siguiente: 

 @RequestMapping(value = "/id")  
    String getIdByValue(@RequestParam("id") String personId) {  
        System.out.println("ID is " + personId);  
        return "Get ID from query string of URL with value element";  
    }  
    @RequestMapping(value = "/personId")  
    String getId(@RequestParam String personId) {  
        System.out.println("ID is " + personId);  
        return "Get ID from query string of URL without value element";  
    }  

 

Condiciones de uso

Si necesita limitar el método de solicitud a un determinado tipo, debe usar las anotaciones simplificadas anteriores. Si necesita permitir varios métodos de solicitud diferentes al mismo tiempo, ¡debe usarlo @RequestMapping!

Con respecto a las @RequestMappinganotaciones, además de agregar antes del método de procesamiento de la solicitud, ¡también puede agregarlo antes de la declaración de la clase del controlador! P.ej:

 

@Controller
@RequestMapping("user")
public class UserController {
}

Cuando la clase de controlador se configura antes de la declaración @RequestMapping("user"), usereste nivel debe agregarse a todas las rutas de solicitud asignadas en la clase actual . Por ejemplo, antes de agregar la configuración, la ruta de acceso es:

http://localhost:8080/springmvc02/reg.do
http://localhost:8080/springmvc02/login.do

Después de agregar la configuración, la ruta de acceso es:

http://localhost:8080/springmvc02/user/reg.do
http://localhost:8080/springmvc02/user/login.do

Generalmente, se recomienda agregar la configuración de esta anotación antes de la declaración de cada clase de controlador.

Se puede ver que cuando el marco SpringMVC procesa la ruta de configuración, @RequestMappingempalmará el valor de configuración antes de la clase y el valor de configuración antes del método como una ruta de acceso completa. Sin embargo, el desarrollador no necesita considerar los /símbolos de la izquierda. y los lados derechos del valor de configuración. Por ejemplo, la siguiente configuración es equivalente:

Configuración antes de la clase de controlador Configuración antes del método
usuario reg.do
usuario /reg.do
usuario/ reg.do
usuario/ /reg.do
/usuario reg.do
/usuario /reg.do
/usuario/ reg.do
/usuario/ /reg.do

 

 

 

 

 

 

 

 

 

En uso real, se recomienda utilizar el primer tipo. Es posible usar otros estilos de configuración, pero en el mismo proyecto, ¡solo se debe usar un estilo de configuración!

@ResponseCuerpo

La función de la anotación @ResponseBody es convertir el objeto devuelto por el método del controlador en un formato específico a través de un convertidor apropiado, y luego escribirlo en el área del cuerpo del objeto de respuesta. Por lo general, se usa para devolver datos JSON o Datos XML. A qué debe prestar atención, después de usar esta anotación, el procesador no se volverá a intentar, pero los datos se escribirán directamente en el flujo de entrada. Su efecto es equivalente a enviar los datos en el formato especificado a través del objeto de respuesta.

@RequestMapping(path = "/hello", method = RequestMethod.POST)
@ResponseBody
public String helloWorld() {
 return "Hello SpringMVC"
}

Interceptador

El papel de los interceptores

El interceptor ( Interceptor) puede actuar en varias solicitudes diferentes en el marco SpringMVC, y después de ser procesado por el interceptor, puede optar por bloquear estas solicitudes (no se permite que continúen ejecutándose en el proceso posterior), o elegir dejarlo ir !

Nota: El papel de un interceptor no es necesariamente que la ejecución no esté permitida después de haber sido "bloqueado". ¡Quizás algunos interceptores están "bloqueando" y los dejan pasar todos!

Interfaz de interceptor

Cuando necesite usar el interceptor, primero, debe personalizar la clase, implementar la HandlerInterceptorinterfaz y agregar declaraciones de salida al método anulado para facilitar la observación del tiempo de ejecución del método y el orden de ejecución:

El interceptor debe implementar la interfaz HandlerInterceptor, que tiene los siguientes 3 métodos

  • preHandle (.)
  • Se llama antes de que se ejecute el procesador. El método devuelve verdadero para indicar que se seguirán llamando a otros interceptores y procesadores; devolver falso indica que el proceso se interrumpe y los interceptores y procesadores posteriores no se ejecutarán
  • postHandle (.)
  • Se llama después de que se ejecuta el procesador y antes de que se procese la vista. En este punto, los datos del modelo se pueden procesar o la vista se puede procesar a través del objeto modelAndView
     
  • afterCompletion (.)
  • Se llama después de que se procesa toda la solicitud. Por ejemplo, en la supervisión del rendimiento, podemos registrar el tiempo de finalización y generar el tiempo de consumo aquí, y también podemos limpiar algunos recursos. Solo cuando preHandle devuelva verdadero, se ejecutará el método afterCompletion
package cn.tedu.spring;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;

public class LoginInterceptor implements HandlerInterceptor {

	@Override
	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {
		System.out.println("LoginInterceptor.preHandle()");
		return true;
	}

	@Override
	public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
			ModelAndView modelAndView) throws Exception {
		System.out.println("LoginInterceptor.postHandle()");
	}

	@Override
	public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
			throws Exception {
		System.out.println("LoginInterceptor.afterCompletion()");
	}

}

Es necesario configurar el interceptor y los requisitos de escritura para la configuración:

  • La configuración relacionada necesita escribir en una clase, esta clase necesita implementar WebMvcConfigurerla interfaz y debe agregarse antes de la declaración de clase @Configurationy @EnableWebMvcestas dos notas, y el objeto de esta clase debe inicializarse como getServletConfigClasses()valor de retorno de la clase del método;

  • Vuelva a escribir el addInterceptors()método en la clase anterior para configurar el interceptor.

Por ejemplo, use la SpringMvcConfigclase de configuración existente :

package cn.tedu.spring;

@EnableWebMvc
@Configuration
@ComponentScan("cn.tedu.spring")
public class SpringMvcConfig implements WebMvcConfigurer {
	
	private String characterEncoding = "utf-8";
	
	@Bean
	public ViewResolver viewResolver() {
		// 省略
	}

	@Override
	public void addInterceptors(InterceptorRegistry registry) {
		HandlerInterceptor interceptor = new LoginInterceptor();
		// 注意:表示拦截器处理的路径时,各路径必须使用 / 作为第1个字符
		registry.addInterceptor(interceptor).addPathPatterns("/index.do");
	}

}

En un proyecto, se permite que existan varios interceptores al mismo tiempo. El orden de configuración determina el orden de ejecución . Si una solicitud pasa por varios interceptores, solo estos interceptores pueden continuar ejecutándose hacia atrás, siempre que uno de ellos El resultado del procesamiento de cualquier interceptor es evitar la operación, ¡la solicitud no se puede ejecutar al revés!

Se puede observar a través del efecto de ejecución:

  • Cuando el preHandle()método en el interceptor regresa true, ejecutará el preHandle()método en el interceptor , luego ejecutará el método en el controlador que necesita ser solicitado, y luego ejecutará el método de postHandle()suma en el interceptor afterCompletion();
  • Cuando preHandle()regrese el método en el interceptor false, solo se ejecutará el preHandle()método en el interceptor y la ventana del navegador del cliente estará en blanco.
  • ¡Sólo el preHandle()método en el interceptor es el método de "intercepción" en el verdadero sentido!

De vuelta en la LoginInterceptorclase, anule el preHandle()método para determinar si debe bloquearlo o dejarlo ir:

Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    System.out.println("LoginInterceptor.preHandle()");
    // 如果已经登录,则放行,如果未登录,则阻止且重定向到登录界面
    HttpSession session = request.getSession();
    if (session.getAttribute("username") == null) {
        String contextPath = request.getContextPath();
        response.sendRedirect(contextPath + "/user/login.do");
        return false;
    }
    return true;
}


Uso de interceptores

En cuanto a la configuración de los interceptores, en primer lugar, ¡cada interceptor se puede configurar con varias rutas de interceptación! En cuanto al addPathPatterns()método llamado al configurar la ruta de interceptación , el código fuente es:

/**
 * Add URL patterns to which the registered interceptor should apply to.
 */
public InterceptorRegistration addPathPatterns(String... patterns) {
    return addPathPatterns(Arrays.asList(patterns));
}

/**
 * List-based variant of {@link #addPathPatterns(String...)}.
 * @since 5.0.3
 */
public InterceptorRegistration addPathPatterns(List<String> patterns) {
    this.includePatterns.addAll(patterns);
    return this;
}

En uso real, se puede escribir como:

registry.addInterceptor(interceptor).addPathPatterns("/index.do", "/user/password.do");

O escrito como:

List<String> pathPatterns = new ArrayList<>();
pathPatterns.add("/index.do");
pathPatterns.add("/user/password.do");
registry.addInterceptor(interceptor).addPathPatterns(pathPatterns);

Al configurar una ruta, también se puede usar un asterisco ( *) como comodín, por ejemplo, se puede /blog/*configurar para interceptar la ruta y, a continuación /blog/delete.do, se /blog/edit.dopueden hacer coincidir otras rutas.

Sin embargo, debe tenerse en cuenta que: 1 asterisco ( *) solo puede indicar recursos por debajo de un cierto nivel y no puede coincidir con varios niveles. Tal como está configurado /blog/*, ¡el partido no podrá hacerlo /blog/2020/list.do! Si el número corresponde a un cierto nivel, debe utilizar dos estrellas consecutiva ( **), por ejemplo, configurado para /blog/**, puede ser igualada a /blog/list.do, /blog/2020/list.do, /blog/2020/07/list.do......

Después de registrar el interceptor, también puede llamar al excludePathPatterns()método para agregar la ruta "excluida", ¡y la ruta "excluida" no será procesada por el interceptor! Por tanto, también se puede entender como "excepción" o "lista blanca", por ejemplo:

List<String> pathPatterns = new ArrayList<>();
pathPatterns.add("/user/reg.do");
pathPatterns.add("/user/handle_reg.do");
pathPatterns.add("/user/login.do");
pathPatterns.add("/user/handle_login.do");
registry.addInterceptor(interceptor)
    .addPathPatterns("/user/**")
    .excludePathPatterns(pathPatterns);

Nota: ¡Al llamar a un método, primero debe llamar al addPathPatterns()método y luego llamar al excludePathPatterns()método!

La diferencia entre interceptor y filtro

lo mismo

Tanto los interceptores como los filtros pueden actuar en varias solicitudes diferentes. El código en el interceptor o filtro se ejecutará antes de que se procese la solicitud, y ambos pueden lograr el efecto de liberación o bloqueo, y ambos tienen "cadenas". El concepto de, múltiples Los interceptores o filtros están permitidos en el mismo proyecto. La misma solicitud debe pasar por varios interceptores o filtros. Solo cuando estos interceptores o filtros estén todos liberados, ¡se puede ejecutar al revés!

la diferencia

  • El filtro es un componente en Java EE, cualquier proyecto Java EE puede usar el filtro, y el interceptor Interceptor es un componente en el marco SpringMVC, solo los proyectos Java EE que usan el marco SpringMVC pueden usar el interceptor, y solo se procesa la solicitud antes de que se procesen los interceptores SpringMVC de tramas, por ejemplo, se establece la ruta SpringMVC de procesamiento de tramas *.do, las páginas HTML de acceso directo, fotografías y otros interceptores de recursos no se procesarán;

  • El filtro Filter se ejecuta antes de todos los componentes del Servlet, y la primera ejecución del interceptor Interceptor es DispatcherServletdespués y antes del componente Controlador (por supuesto, cuando se usa un filtro, quizás la solicitud se procesa a través de Servlet, usando intercepción Cuando se usa el controlador, el la solicitud se procesa a través del controlador, por lo que estos dos se ejecutan antes de que se procese la solicitud, por lo que, en general, la diferencia no es obvia);

  • El filtro solo puede configurar la ruta de filtrado (lista negra), mientras que el interceptor Interceptor puede configurar tanto la ruta de interceptación (lista negra) como la ruta de exclusión (excepción, lista blanca) ¡La configuración de este último es más flexible!

Condiciones de uso

Al analizar las diferencias anteriores, se puede encontrar que el efecto logrado por el filtro se puede lograr básicamente utilizando el interceptor ¡Interceptor! Al mismo tiempo, el interceptor también tiene las características de "configuración más flexible", por lo que en la mayoría de los casos, ¡el interceptor debe usarse primero!

Por supuesto, el filtro también tiene la característica de que el interceptor no puede ser reemplazado, es decir, el "punto de tiempo de ejecución" es muy temprano, se ejecuta antes que todos los componentes del Servlet, por lo que si una tarea que necesita ser "bloqueada" para su ejecución es muy temprano Para ejecutar, debes usar un filtro!

 

Por ejemplo, la codificación predeterminada utilizada por el marco SpringMVC es ISO-8859-1que no es compatible con el chino. Por lo tanto, POSTsiempre que haya caracteres que no sean ASCII en los parámetros de la solicitud enviada, habrá caracteres confusos. Si necesita personalizar la codificación, debe ingresar la clase de inicialización del proyecto Reescribir el getServletFilters()método y devolver el filtro de codificación de caracteres que viene con el marco SpringMVC en este método, y establecer la codificación, por ejemplo:

Solución confusa china

Cuando se envía el formulario, si encuentra caracteres chinos, habrá caracteres distorsionados. Spring proporciona un filtro CharacterEncodingFilter, que se puede utilizar para resolver el problema distorsionado.
Preste atención a los siguientes problemas al usar CharacterEncodingFilter

  • Los datos del formulario son enviados por POST
  • Configure el filtro CharacterEncodingFilter en web.xml
  • La codificación de la página y la codificación especificada por el filtro deben ser coherentes
     
@Override
protected Filter[] getServletFilters() {
    return new Filter[] { new CharacterEncodingFilter("UTF-8") };
}

Resumen de la etapa SpringMVC

  • [Comprensión] El papel del marco SpringMVC: resolver el problema de la interacción VC;

  • [Comprensión] El diagrama de flujo de ejecución central del marco SpringMVC;

  • [Maestro] Reciba y procese solicitudes de clientes a través del marco SpringMVC:

    • Construcción del proyecto SpringMVC: agregue spring-webmvcdependencias, configure sin web.xml , agregue el entorno Tomcat, cree la clase de configuración SpringMVC, cree la clase del proyecto de inicialización y cargue la clase de configuración SpringMVC, establezca la ruta de solicitud procesada por el marco SpringMVC;

    • Cree una clase de controlador: un nombre personalizado, que debe colocarse en el paquete escaneado por el componente o sus descendientes, y debe agregarse una @Controlleranotación;

    • Cree un método para procesar la solicitud: use una @RequestMappingserie de anotaciones para configurar la ruta de la solicitud, use la publicautoridad de acceso y úsela provisionalmente Stringcomo el tipo de valor de retorno, el nombre del método se puede personalizar y la lista de parámetros del método puede ser diseñado según sea necesario.

  • [Maestro] Reciba los parámetros de solicitud enviados por el cliente a través del marco SpringMVC:

    • Declare los parámetros de la solicitud uno por uno como los parámetros del método para procesar la solicitud;

    • Encapsule varios parámetros de solicitud en un objeto personalizado y declare el tipo de datos personalizados como un parámetro del método que procesa la solicitud.

  • [Maestro] Utilice SpringMVC para encapsular los datos reenviados al componente de vista y mostrar los datos reenviados en el componente de vista;

  • [Comprensión] La diferencia entre reenvío y redirección;

  • [Maestro] Los principios y métodos de uso de Session;

  • [Maestro] El uso y configuración de interceptores;

  • [Comprensión] La diferencia entre interceptores y filtros;

  • [Maestro] Resuelve el problema de los caracteres chinos confusos en la solicitud POST;

  • [Maestro] Leer código fuente anotado simple, como @RequestMapping, @RequestParametc.

Supongo que te gusta

Origin blog.csdn.net/c202003/article/details/107191540
Recomendado
Clasificación