Wie implementieren Sie die 3.1 mvcannotationDiven von Spring?

Question

Dies ist das Codebeispiel aus der Frühjahr 3.1 Spring Source Blog: Von XML zu @Configuration Ich versuche in meiner Anwendung zu implementieren (was im Frühjahr 2.0 nicht von mir durchgeführt wurde, also ist es viel Lernen).

@FeatureConfiguration
class MvcFeatures {

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

    // ...

}

Ich kann jedoch nicht den Punkt von verstehen .ArgumentResolvers (neuer CustomarGumentResolver ()) und ihr CustomargumentResolver sieht aus wie bellow. Was ist der Sinn davon?

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

Um die Antwort von @garyf hinzuzufügen und einige Punkte zu verdeutlichen, führte der Frühjahr 2.5 annotierte Controller ein, die die alten Controller im Schnittstellenstil von Spring 2.0 ersetzten. Diese neuen Controller haben Methoden ohne feste Parameter - die Methode deklariert die Parameter, die sie für ihren Job benötigen, und nichts weiter.

Nehmen wir beispielsweise an, dass eine Controller -Methode eine Sache benötigt, um ihren Job zu erledigen - ein Anforderungsparameter, der die ID eines Objekts aus der Datenbank enthält. Im Frühjahr 2.0 müssten Sie so etwas implementieren wie AbstractController.handleRequestInternal(), z.B

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

Frühling 2.5 machte das einfacher:

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

Hier deklarieren wir nur Parameter für das, was wir brauchen.

So weit so gut, aber hier ist ein Brauch WebArgumentResolver kommt herein. Sagen Sie, ich möchte das entfernen getObjById Insgesamt von meinem Controller, weil es vielleicht denke, dass er den Code aufgreift und vielleicht bei vielen anderen Controller -Methoden verwendet wird. Stattdessen möchte ich das tun:

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

Es ist noch einfacher und verfügt über ein Minimum an Boilerplate -Code. Ein Brauch WebArgumentResolver Kann mit dem App-Kontext registriert werden, der Parameter des Typs erkennt MyThing, und weiß, wie man die Informationen aus der Anfrage extrahiert. Feder ruft diesen Resolver auf und übergibt das Ergebnis an die Controller -Methode.

Benutzerdefinierte Resolver werden häufig nicht verwendet, können jedoch in der richtigen Situation sehr praktisch sein.

Das Beispiel in Ihrer Frage verwendet verwendet CustomArgumentResolver Um den Brauch des Beispiels zu beheben RequestAttribute Klasse. Der Resolver zieht Anforderungsattribute heraus und bindet sie an RequestAttribute Objekte, damit sie als Controller -Methode -Parameter deklariert werden können.

Answer 2

WebArgumentResolvers sind eine Möglichkeit für Sie, anzugeben, wie die Parameter von MVC-ampassenden Methoden aufgelöst werden sollten. Wenn Sie ein benutzerdefiniertes Objekt als Parameter für eine von MVC eingebaute Methode verwenden möchten, versucht Spring herauszufinden, wie es auf eigene Weise Sinn daraus macht. In der Regel würde dies durch Bindung geschehen, wobei einige HTTP -Parameter, die Sie einreichen, mit den Feldern des Objekts übereinstimmen und Spring ihnen übereinstimmen und ein neues Objekt für Sie erstellen.

Wenn Sie jemals eine Situation haben, in der die eingereichten Parameter nicht ganz so ordentlich mit Ihren Methodenparametern übereinstimmen, sind WebarGumentResolvers dazu da, die Lücke zu füllen: Sie bieten eine benutzerdefinierte Logik, sodass der Frühling sie nicht herausfinden muss.

In Ihrem Beispiel ist Param ein solcher Parameter, der übereinstimmt. Dieser benutzerdefinierte Code überprüft zuerst, ob der Parameter eine @RequestAttribute -Annotation hat. Wenn dies der Fall ist, zieht der benutzerdefinierte Code den Wert aus diesem Objekt und schaut ihn als Attribut für die HTTP -Anforderung nach, um ihn zurückzugeben. Es gibt nicht diese Annotation, dann gibt die Methode den ungelösten Wert zurück, was lediglich anzeigt, dass dieses WebargumentResolver nichts über diesen bestimmten Parameter weiß und eine andere Methode (z. B. Bindung) ausprobieren sollte.