Spring MVC: please explain difference between @RequestParam and @ModelAttribute

Lydia Ralph picture Lydia Ralph · Mar 31, 2015 · Viewed 44.5k times · Source

I'm new to Spring MVC. Please help me unpack the documentation.

Documentation

Spring MVC Documentation states (emphasis mine):

  • @ModelAttribute on a method argument indicates the argument should be retrieved from the model. If not present in the model, the argument should be instantiated first and then added to the model. Once present in the model, the argument’s fields should be populated from all request parameters that have matching names. The WebDataBinder class matches request parameter names — including query string parameters and form fields — to model attribute fields by name.

  • @RequestParam binds request parameters to a method parameter in your controller.

Disclaimer / Clarifier

I know that @ModelAttribute and @RequestParam are not the same thing, are not mutually exclusive, do not perform the same role, and can be used simultaneously, as in this question - indeed, @RequestParam can be used to populate fields of @ModelAttribute. My question is more geared towards the difference between their internal workings.

Question:

What is the difference between @ModelAttribute (used on a method argument, not method) and @RequestParam? Specifically:

  • Source: Do @RequestParam and @ModelAttribute have the same source of information / population, i.e. request parameters in URL, which may have been supplied as elements of a form / model that was POSTed?
  • Usage: Is it correct that variables retrieved with @RequestParam are thrown away (unless passed into a model), whereas variables retrieved with @ModelAttribute are automatically fed into the model to be returned?

Or in very basic coding examples, what is the real working difference between these two examples?

Example 1: @RequestParam:

// foo and bar are thrown away, and are just used (e.g.) to control flow?
@RequestMapping(method = RequestMethod.POST)
public String testFooBar(@RequestParam("foo") String foo,
@RequestParam("bar") String bar, ModelMap model) {
    try {
     doStuff(foo, bar);
    }
    // other code
  }

Example 2: @ModelAttribute:

// FOOBAR CLASS
// Fields could of course be explicitly populated from parameters by @RequestParam
public class FooBar{
    private String foo;
    private String bar;
   // plus set() and get() methods
}

// CONTROLLER
// Foo and Bar become part of the model to be returned for the next view?
@RequestMapping(method = RequestMethod.POST)
public String setupForm(@ModelAttribute("fooBar") FooBar foobar) {
   String foo = fooBar.getFoo();
   String bar = fooBar.getBar();
   try {
      doStuff(foo, bar);
   }
   // other code
}

My current understanding:

@ModelAttribute and @RequestParam both interrogate the request parameters for information, but they use this information differently:

  • @RequestParam just populates stand-alone variables (which may of course be fields in a @ModelAttribute class). These variables will be thrown away when the Controller is done, unless they have been fed into the model.

  • @ModelAttribute populates the fields of a class, which then populates an attribute of the model to be passed back to the view

Is this correct?

Answer

zmf picture zmf · Mar 31, 2015

@RequestParam just populates stand-alone variables (which may of course be fields in a @ModelAttribute class). These variables will be thrown away when the Controller is done, unless they have been fed into the model.

Don't confuse the word "model" with session. The http conversation is generally: HTTP.GET, server response, then HTTP.POST. When you have the @ModelAttribute annotation in use you are always constructing an instance of whatever you have annotated, this is what makes you think that 'feeding things to the model' might make variables stick around. This isn't correct, once the HttpServletRequest has finished those variables should no longer be a part of the browser/server conversation unless they've been saved in a session.

@ModelAttribute populates the fields of a class, which then populates an attribute of the model to be passed back to the view

Yes! To be correct, @ModelAttribute tells Spring to use its default web data binder to populate an instance of something with data from the HttpServletRequest. Choosing to pass this data back to the view is up to the programmer. When you have a method annotated with @ModelAttribute, it is being called every time code hits that servlet. When you have @ModelAttribute as one of the method's parameters, we are talking about incoming Http form data-binding.

Calling @RequestParam is a shortcut for saying request.getParameter("foo"); under the hood, Java's HttpServletRequest lets you get values from the request object by doing a key->value look up. The value returned is of type Object. This is what you would be typing a lot if you were not using Spring in your web application.

Spring then takes this abstraction a step further when you start to use @ModelAttribute. This annotation employs the concept of data-binding. The goal of data-binding is that the code in your controller won't have to call request.getParameter("foo1"), for every form element. Imagine you have a web form with 5 fields. Without data-binding the programmer has to manually retrieve, and validate each of those fields. The programmer has to make sure that the request contains the property, that the property's value exists, and that the property's value is of the type expected for each field. Using @ModelAttribute tells Spring to do this work for you.

If you annotate a method in your controller with @ModelAttribute("fooBar") FooBar fooBar An instance of FooBar will always be constructed by Spring, and supplied to your method. Where the data binding comes into play, is when this annotation is used in a Method's parameters; Spring looks at the instance of HttpServletRequest and sees if it can match the data in the request to the right property on an instance of FooBar. This is based off the java properties convention, where you have a field such as foo and public getters and setters called getFoo and setFoo. This might seem magic but if you were to break convention, your Spring data binding would stop working because it wouldn't be able to know where to bind the data from your HttpServletRequest You would still get an instance of FooBar, but the properties would not be set to any values from the request.