¿Cómo implementar el 3,1 MVCannotationation de Spring?

Question

Este es el ejemplo de código de la primavera 3.1 Blog de Spring Source: de XML a @Configuration Estoy tratando de implementar en mi aplicación (que se realizó en Spring 2.0 no por mí, por lo que es mucho aprendizaje).

@FeatureConfiguration
class MvcFeatures {

    @Feature
    public MvcAnnotationDriven annotationDriven(ConversionService conversionService) {
        return new MvcAnnotationDriven().conversionService(conversionService)
            .argumentResolvers(new CustomArgumentResolver());
    }

    // ...

}

Sin embargo, no puedo entender el punto de .argumentResolvers (New CustomarGumentResolver ()) Y su CustomargumentResolver parece a continuación. ¿Cuál es el punto de eso?

public class CustomArgumentResolver implements WebArgumentResolver {

    @Override
    public Object resolveArgument(MethodParameter param, NativeWebRequest request) throws Exception {
        RequestAttribute attr = param.getParameterAnnotation(RequestAttribute.class);
        if (attr != null) {
            return request.getAttribute(attr.value(), WebRequest.SCOPE_REQUEST);
        } else {
            return WebArgumentResolver.UNRESOLVED;
        }
    }
}

Answer 1

Para agregar a la respuesta de @Garyf, y para aclarar algunos puntos, Spring 2.5 introdujo controladores anotados, que reemplazaron los viejos controladores de estilo interfaz de Spring 2.0. Estos nuevos controladores tienen métodos sin parámetros fijos: el método declara los parámetros que necesita para hacer su trabajo y nada más.

Por ejemplo, digamos que un método del controlador necesitaba una cosa para hacer su trabajo: un parámetro de solicitud que contiene la ID de un objeto de la base de datos. En la primavera 2.0, necesitaría implementar algo como AbstractController.handleRequestInternal(), p.ej

protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) {
   String id = request.getParameter("id");
   MyThing obj = getObjById(id);
   //... do stuff and return ModelAndView
}

La primavera 2.5 lo hizo más fácil:

@RequestMapping
public ModelAndView handle(String id) {
   MyThing obj = getObjById(id);
   //... do stuff and return ModelAndView
}

Aquí, solo declaramos parámetros para las cosas que necesitamos.

Hasta ahora todo bien, pero aquí es donde una costumbre WebArgumentResolver entra. Digamos que quiero eliminar el getObjById De mi controlador por completo, porque tal vez creo que clora el código, y tal vez se usa en muchos otros métodos del controlador. En cambio, quiero hacer esto:

@RequestMapping
public ModelAndView handle(MyThing id) {
   //... do stuff and return ModelAndView
}

Es aún más simple y tiene un mínimo de código de calderas. Una costumbre WebArgumentResolver se puede registrar con la aplicación contexto que reconoce los parámetros de tipo MyThing, y sabe cómo extraer la información de la solicitud. Spring invoca ese resolución y pasa el resultado al método del controlador.

Los solucionadores personalizados no se usan comúnmente, pero pueden ser muy útiles en la situación correcta.

El ejemplo en su pregunta usa CustomArgumentResolver Para resolver la costumbre del ejemplo RequestAttribute clase. El resolución retira los atributos de la solicitud y los vincula a RequestAttribute objetos, para que puedan declararse como parámetros del método del controlador.

Answer 2

WebArgumentResolverS son una forma de especificar cómo se deben resolver los parámetros de los métodos mapados de MVC. Si desea utilizar un objeto personalizado como parámetro para un método mapado de MVC, Spring intenta descubrir cómo darle sentido a su propio camino. Por lo general, esto sucedería a través de la unión, donde algunos parámetros HTTP que envían coinciden con los campos del objeto y la primavera los coincide y crea un nuevo objeto para usted.

Si alguna vez tiene una situación en la que los parámetros enviados no coinciden tan bien con los parámetros de su método, WebArgumentResolvers está allí para completar el espacio: proporciona una lógica personalizada, por lo que Spring no tiene que resolverlo.

En su ejemplo, Param es uno de esos parámetros que se combinará. Esta pieza de código personalizado primero verifica si el parámetro tiene una anotación @RequestatTribute. Si lo hace, el código personalizado extrae el valor de ese objeto y lo busca como un atributo en la solicitud HTTP, devolviéndolo. No tiene esa anotación, entonces el método devuelve el valor no resuelto, lo que simplemente indica que este WebargumentResolver no sabe nada sobre este parámetro particular y resorte debería probar un método diferente (como la unión).