Spring MVC - The Basics

Spring MVC - The Basics
Ilio Catallo - info@iliocatallo.it

Outline
• MVC and MVC 2
• Request processing pipeline
• Se8ng up Spring MVC
• Wri:ng Controllers
• References

Model-View-Controller
The Model-View-Controller (MVC) pa5en was invented at Xerox
Parc by Trygve Reenskaug in 1979

MVC pa'ern
Applica'ons should have three major parts
• The part that manages the data
• The part that creates screens and reports
• The part that handles interac3ons between the user and the
other subsystems

MVC pa'ern
• Model
• View
• Controller

MVC pa'ern
• Domain model
• View
• Controller

What is the reason not to use the same MVC pa2ern also for Web
applica7ons?

HTTP limita*ons
The reason is that the HTTP protocol limits the applicability of the
MVC pa7ern

Stateless protocol
The MVC pa*ern requires a stateful protocol to keep track of the
applica.on state

Applica'on state
"If we think of an applica1on as being computerized behavior that
achieves a goal, we can describe an applica1on protocol as the set of
legal interac1ons necessary to realize that behavior. Applica3on state
is a snapshot of an execu1on of such an applica1on protocol."
(J. Webber et al.)

Stateless protocol
However, HTTP is stateless

Pull protocol
The MVC pa*ern requires a push protocol for the views to be
no7ﬁed by the model

Pull protocol
However, HTTP is a pull protocol: no request implies no response

How can we overcome such limita2ons?

Stateless protocol
HTTP is stateless: we can implement the MVC design pa3ern on
top of the Java Servlet Pla;orm

Stateless protocol
The Java Servlet Pla-orm provides a session context to help track
users in the applica8on

Pull protocol
HTTP is a pull protocol: we can increase the Controller
responsibility

Pull protocol
Namely, the Controller will be responsible for:
• State changes
• State queries
• Change no2ﬁca2ons

MVC 2 pa(ern
The resul)ng pa.ern is some)mes called MVC 2 or Web MVC
+-------------+ +---------------+ +----------------+
| +----------> +---------> |
| View | | Controller | | Domain model |
| <----------+ <---------+ |
+-------------+ +---------------+ +----------------+

MVC 2 pa(ern
Any state query or change no0ﬁca0on must pass through the
Controller
+-------------+ +---------------+ +----------------+
| +----------> +---------> |
| <----------+ <---------+ |
+-------------+ +---------------+ +----------------+

MVC 2 pa(ern
The View renders data passed by the Controller rather than data
returned directly from the Model
+-------------+ +---------------+ +----------------+
| +----------> +---------> |
| <----------+ <---------+ |
+-------------+ +---------------+ +----------------+

MVC 2 pa(ern
We refer to such data as the view model
+-------------+ +---------------+ +----------------+
| +--------------> +---------> |
| <--View model--+ <---------+ |
+-------------+ +---------------+ +----------------+

Compe&ng architectures
Note that MVC 2 proposes a compe&ng architecture to the one
we presented during the last lecture
┌──────┐┌────────────────────────────────┐
│ D ││ │
│ o ││ Presentation layer │
│ m ││ │
│ a │└────────────────────────────────┘
│ i │┌────────────────────────────────┐
│ n ││ │
│ ││ Service layer │
│ m ││ │
│ o │└────────────────────────────────┘
│ d │┌────────────────────────────────┐
│ e ││ │
│ l ││ Persistence layer │
│ ││ │
└──────┘└────────────────────────────────┘

We reconcile the two architectures by limi3ng the scope of the
MVC 2 pa;ern to the sole presenta(on layer
┌──────┐┌────────────────────────────────┐
│ D ││ │
│ o ││ Presentation layer │
│ m ││ │
│ a │└────────────────────────────────┘
│ i │┌────────────────────────────────┐
│ n ││ │
│ ││ Service layer │
│ m ││ │
│ o │└────────────────────────────────┘
│ d │┌────────────────────────────────┐
│ e ││ │
│ l ││ Persistence layer │
│ ││ │
└──────┘└────────────────────────────────┘

What is Spring MVC?
Spring MVC is an open source MVC 2 framework for developing
Web applica3ons

Spring MVC
Spring MVC eases Web applica2on development
• It provides a ready-to-use MVC 2 Controller
• It promotes Spring’s loosely coupled techniques in the
presenta>on layer of an applica>on

DispatcherServlet
Spring MVC is designed around a central servlet named
DispatcherServlet
Presentation layer
+---------------------------------+
| |
| |
| |
| +-----------------------+ |
| | | |
| | DispatcherServlet | |
| | | |
| +-----------------------+ |
| |
| |
| |
| |
+---------------------------------+

DispatcherServlet
DispatcherServlet acts as a centralized entry point to the
Web applica.on
Presentation layer
+---------------------------------+
| |
| |
| |
+---------------+ | +-----------------------+ |
| | Request | | | |
| Browser +--------------> DispatcherServlet | |
| | | | | |
+---------------+ | +-----------------------+ |
| |
| |
| |
| |
+---------------------------------+

DispatcherServlet
That is, every request is handled by DispatcherServlet
Presentation layer
+---------------------------------+
| |
| |
| |
+---------------+ | +-----------------------+ |
| | Request | | | |
| Browser +--------------> DispatcherServlet | |
| | | | | |
+---------------+ | +-----------------------+ |
| |
| |
| |
| |
+---------------------------------+

DispatcherServlet
DispatcherServlet is an expression of the front controller
pa.ern
Presentation layer
+---------------------------------+
| |
| |
| |
+---------------+ | +-----------------------+ |
| | Request | | | |
| Browser +--------------> Front Controller | |
| | | | | |
+---------------+ | +-----------------------+ |
| |
| |
| |
| |
+---------------------------------+

The Front Controller
The Front controller’s job is to determine a suitable handler
capable of performing the actual processing
Presentation layer
+---------------------------------+
| |
| |
| |
+---------------+ | +-----------------------+ |
| | Request | | | |
| | | | | |
+---------------+ | +-----------+-----------+ |
| | |
| | |
| | |
| +--------v---------+ |
| | | |
| | Handler | |
| | | |
| +------------------+ |
| |
| |
+---------------------------------+

Controllers
Handlers are nearly always Spring MVC controllers
Presentation layer
+---------------------------------+
| |
| |
| |
+---------------+ | +-----------------------+ |
| | Request | | | |
| | | | | |
+---------------+ | +-----------+-----------+ |
| | |
| | |
| | |
| +--------v---------+ |
| | | |
| | Controller | |
| | | |
| +------------------+ |
| |
| |
+---------------------------------+

Model
The selected Controller interacts with the service layer; the
relevant data are collected in a view model
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| Browser | | | Front controller | | +-> Service layer |
| | | | | | | +--------+----------+
+-------------+ | +-------------------+-------+ | | |
| | | | |
| | | | +--------v----------+
| | | | | Persistence layer |
| | | | +--------+----------+
| | | | |
| +---v----------+ | | v
| | | | | +--+---+
| | Controller <-----+ | |
| | | | | DB |
| +--------------+ | | |
+--------------------------------------+ +------+

Model
The selected Controller interacts with the service layer; the
relevant data are collected in a view model
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-------------------+-----^-+ | | |
| | | | | |
| | +---+---+ | | +--------v----------+
| | | Model | | | | Persistence layer |
| | +---+---+ | | +--------+----------+
| | | | | |
| +---v-----+----+ | | v
| | | | | +--+---+
| | Controller <-----+ | |
| | | | | DB |
| +--------------+ | | |
+--------------------------------------+ +------+

Model
Spring MVC refers to the view model simply as the model. This may
lead to confusion with the classic MVC terminology
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-------------------+-----^-+ | | |
| | | | | |
| | +---+---+ | | +--------v----------+
| | +---+---+ | | +--------+----------+
| | | | | |
| +---v-----+----+ | | v
| | | | | +--+---+
| | Controller <-----+ | |
| | | | | DB |
| +--------------+ | | |
+--------------------------------------+ +------+

Model
Regardless the name, remember that the model consists of data the
Controller prepares just for the view
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-------------------+-----^-+ | | |
| | | | | |
| | +---+---+ | | +--------v----------+
| | +---+---+ | | +--------+----------+
| | | | | |
| +---v-----+----+ | | v
| | | | | +--+---+
| | Controller <-----+ | |
| | | | | DB |
| +--------------+ | | |
+--------------------------------------+ +------+

Controllers
When the controller has ﬁnished processing, the front controller
determines which view to render
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-------------------+-----^-+ | | |
| | | | | |
| | +---+---+ | | +--------v----------+
| | +---+---+ | | +--------+----------+
| | | | | |
| +-------------+ +---v-----+----+ | | v
| | | | | | | +--+---+
| | View | | Controller <-----+ | |
| | | | | | | DB |
| +-------------+ +--------------+ | | |
+--------------------------------------+ +------+

Views
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-------+-----------+-----^-+ | | |
| | | | | | |
| +---+---+ | +---+---+ | | +--------v----------+
| | Model | | | Model | | | | Persistence layer |
| +---+---+ | +---+---+ | | +--------+----------+
| | | | | | |
| +--------v----+ +---v-----+----+ | | v
| | | | | | | +--+---+
| | | | | | | DB |
| +-------------+ +--------------+ | | |
+--------------------------------------+ +------+

Views
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| | | | | | | +--------+----------+
+-------------+ | +-^-----+-----------+-----^-+ | | |
| | | | | | | |
| | +---+---+ | +---+---+ | | +--------v----------+
| | | Model | | | Model | | | | Persistence layer |
| | +---+---+ | +---+---+ | | +--------+----------+
| | | | | | | |
| +--+-----v----+ +---v-----+----+ | | v
| | | | | | | +--+---+
| | | | | | | DB |
| +-------------+ +--------------+ | | |
+--------------------------------------+ +------+

Views
Presentation layer
+--------------------------------------+
| |
+-------------+ Request | +---------------------------+ |
| +--------------> | | +-------------------+
| +<-------------+ | | | +--------+----------+
+-------------+ Response| +-^-----+-----------+-----^-+ | | |
| | | | | | | |
| | +---+---+ | +---+---+ | | +--------v----------+
| | | Model | | | Model | | | | Persistence layer |
| | +---+---+ | +---+---+ | | +--------+----------+
| | | | | | | |
| +--+-----v----+ +---v-----+----+ | | v
| | | | | | | +--+---+
| | | | | | | DB |
| +-------------+ +--------------+ | | |
+--------------------------------------+ +------+

Se#ng up Spring MVC
Se#ng up Spring MVC is a two-step process
1. Loading DispatcherServlet in the Web container
2. Instan5a5ng a DI container and the related beans

1. Loading DispatcherServlet in the Web container

Loading the front controller
We need to tell the Web container to load DispatcherServlet

To this end, we provide the Web container with a web.xml
deployment descriptor ﬁle
+ Web components
| (e.g., servlets)
|
+-------v--------+
| |
| Web |
web.xml +--------> container |
| |
+-------+--------+
|
|
v Web app

Recall that the web.xml ﬁle describes how to deploy the Web
components of an applica6on
+ Web components
| (e.g., servlets)
|
+-------v--------+
| |
| Web |
web.xml +--------> container |
| |
+-------+--------+
|
|
v Web app

<servlet>
<servlet-name>frontcontroller</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>frontcontroller</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>

2. Instan)a)ng a DI container and the related beans

Instan&a&ng beans
DispatcherServlet instan'ates a Spring DI container
+---------------------------------------------------+
| |
| |
| |
| +------------+ +------------+ |
| | +------------+ | +------------+ |
| | | +-------------+ | | +-------------+ |
| | | | | | | | | |
| +-+ | Controllers | +-+ | Special | |
| +-+ | +-+ beans | |
| +-------------+ +-------------+ |
| |
| |
| |
+---------------------------------------------------+
Spring DI Container

Instan&a&ng beans
Such a container hosts beans belonging to the presenta(on layer
• Controllers
• Special beans

Controllers
Controllers are wri'en by the developer and provide access to the
service layer of the applica5on
@Controller
public class AccountController {
...
}

Special beans
Special beans are beans that are already part of Spring MVC

Special beans
More precisely, special beans are DispatcherServlet's
collaborators

Special beans
DispatcherServlet relies on them to process requests and
render the appropriate views

Special beans
Each special bean plays its own small part in the overall processing
of the request

Special beans
For instance:
• HandlerMapping maps HTTP requests to handlers
• ViewResolver maps logical name to views
• HandlerExceptionResolver maps excep:ons to handlers

Special bean interfaces
Each special bean is expressed as an interface
public interface ViewResolver {
View resolveViewName(String viewName, Locale locale);
}

Special bean advantages
Thanks to this, the request processing pipeline is highly ﬂexible
and conﬁgurable

Special bean advantages
Indeed, we can tailor each stage of the pipeline just by changing its
concrete implementa9on
public class VelocityViewResolver implements ViewResolver { ... }
public class XmlViewResolver implements ViewResolver { ... }
public class InternalResourceViewResolver implements ViewResolver { ... }

Default special beans
For each special bean, the DispatcherServlet maintains a list
of implementa)ons to be used by default

For instance, InternalResourceViewResolver is instan-ated
by default
public class InternalResourceViewResolver implements ViewResolver { ... }

If not stated otherwise, DispatcherServlet will use default
implementa4ons throughout the en4re processing pipeline

Web beans
Controllers and special beans are the Web beans of our applica3on
+---------------------------------------------------+
| |
| |
| |
| +------------+ +------------+ |
| | +------------+ | +------------+ |
| | | +-------------+ | | +-------------+ |
| | | | | | | | | |
| +-+ | +-+ beans | |
| +-------------+ +-------------+ |
| |
| |
| |
+---------------------------------------------------+
Spring DI Container

WebApplicationContext
The container we obtain is of type WebApplicationContext
+---------------------------------------------------+
| |
| |
| |
| +------------+ +------------+ |
| | +------------+ | +------------+ |
| | | +-------------+ | | +-------------+ |
| | | | | | | | | |
| +-+ | +-+ beans | |
| +-------------+ +-------------+ |
| |
| |
| |
+---------------------------------------------------+
Spring DI Container

WebApplicationContext
WebApplicationContext extends the ApplicationContext
interface with some extra features necessary for Web applica7ons
public interface WebApplicationContext extends ApplicationContext {
...
}

frontcontroller-servlet.xml
In par'cular, the container looks in WEB-INF/ for an XML ﬁle
named frontcontroller-servlet.xml1
1
More generally, the servletName in servletName-servlet.xml must be the same as the <servlet-name>
speciﬁed in web.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation=”...">

</beans>

Overriding defaults
By altering frontcontroller-servlet.xml, we can
customize or replace default beans within the container

Overriding defaults
Example: customizing InternalResourceViewResolver
<bean class="org.springframework.web.
servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>

Controllers
Controllers are responsible for responding to the ac#ons the user
takes on the user interface
• Submi'ng a form
• Clicking on a link
• Accessing a page

Types of controllers
There exist two op-ons for wri-ng controllers
• Using the @Controller annota-on
• Implemen-ng the Controller interface2
2
Do not use this approach. The only reason why the Controller interface is s5ll available is to preserve
compa5bility with legacy code

Annotated controllers
To write annotated controllers we need to use the @Controller
annota/on
@Controller
public class GreetingController {
...
}

Annotated controllers
The @Controller annota)on indicates that a par)cular class
serves the role of a controller
@Controller
...
}

Auto-detec)ng controllers
A simple addi+on to frontcontroller-servlet.xml allows
the container to auto-detect annotated controllers
<context:component-scan
base-package="it.polimi.awt.springmvc.web"/>

Auto-detec)ng controllers
The <context:component-scan> element recursively scans a
package, looking for classes to be automa8cally registered as beans
<context:component-scan
base-package="it.polimi.awt.springmvc.web"/>

@RequestMapping
The @RequestMapping annota)on is used to map URLs to
handler methods
@Controller
@RequestMapping("/greeting")
public String getGreeting() { ... }
}

@RequestMapping
The /greeting URL is mapped to getGreeting()
public String getGreeting() { ... }

Unique endpoints
Think of handler methods as unique endpoints, with mappings
derived from the related @RequestMapping annota6ons
public String getGreeting() {...}

Annotated controllers upsides
When you open a controller, you can see which URLs the controller
is mapped to

Annotated controllers downsides
The mapping is sca$ered throughout the codebase, making it
harder to see which URL is mapped to which handler method

Mapping URLs to handlers
In order to interpret the mappings deﬁned in the controller class,
Spring MVC needs a HandlerMapping implementa8on

Determining which handler to call
The HandlerMapping interface provides the abstrac2on for
mapping requests to handlers3
public interface HandlerMapping {
public HandlerExecutionChain getHandler(HttpServletRequest request);
}
3
The getHandler method returns a HandlerExecutionChain only because of the need of accoun4ng for
possible interceptors. Conceptually, we can s4ll assume the method to return a handler

Overriding HandlerMapping
DefaultAnnotationHandlerMapping is the default
implementa-on of HandlerMapping
public class DefaultAnnotationHandlerMapping implements HandlerMapping { ... }

As of Spring 3, the suggested implementa.on became
RequestMappingHandlerMapping
public class DefaultAnnotationHandlerMapping implements HandlerMapping { ... }
public class RequestMappingHandlerMapping implements HandlerMapping { ... }

RequestMappingHandlerMapping is a HandlerMapping
implementa+on that allows performing more advanced opera+ons
• Data valida*on
• Wri*ng and reading JSON
• Date and numbers support

To start using RequestMappingHandlerMapping, it is suﬃcient
to alter frontcontroller-servlet.xml so as to add
<mvc:annotation-driven/>

Responsibili*es
We already know that the Web layer has two responsibili-es
1. Glueing together the service layer and the Web
2. Taking care of the naviga;on logic

Responsibili*es
Let us now see how to implement such responsibili2es in prac(ce
1. Glueing together the service layer and the Web
2. Taking care of the naviga;on logic

1. Interac+ng with the service layer

Interac(ng with the service layer
A"er being invoked, the controller processes the HTTP request
and interacts with the service layer
+---------------+ +----------------+
| +---------> |
| Controller | | Service layer |
| <---------+ |
+---------------+ +----------------+

GreetingService
For instance, we may assume that in our ﬁc3onal applica3on, the
user can request a random gree3ng
public interface GreetingService {
public String getRandomGreeting();
}

GreetingService implementa*on
public class NaiveGreetingService implements GreetingService {
private List<String> greetings;
public NaiveGreetingService() {
this.greetings = Arrays.asList(
"Hello sweetie",
"Valar morghulis",
"Tiger tiger"
);
}
@Override
public String getRandomGreeting() {
int index = ThreadLocalRandom.current().nextInt(greetings.size());
return greetings.get(index);
}
}

Execu&ng the use case
Within the handler method, we ﬁrst execute the related use case
@Controller
private GreetingService service;
public String getGreeting() {
// execute the related use case
String greeting = service.getRandomGreeting();
...
}
}

Such an invoca+on may result in an arbitrarily complex object
@Controller
...
}
}

However, in this case we end up with a simple String
@Controller
...
}
}

Model
Once we collected the use case outcome, the next step is to build a
model object
+--------------+ +--------------------+ +----------------+
| | +----------+ | | +----------+ | |
| View <--+ Model +--+ Front Controller <--+ Model +--+ Controller |
| | +----------+ | | +----------+ | |
+--------------+ +--------------------+ +----------------+

Model
This model object will contain the frac%on of the outcome that
holds some signiﬁcance for the next view to render
+--------------+ +--------------------+ +----------------+
| | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | |
+--------------+ +--------------------+ +----------------+

Model
The view will use the model to build up the dynamic parts of the
user interface
+--------------+ +--------------------+ +----------------+
| | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | |
+--------------+ +--------------------+ +----------------+

Model
The model is the collec+on of named objects needed by the view
in order to render itself
+---------------+--------------+
| key1 | value1 |
+------------------------------+
| key2 | value2 |
+------------------------------+
| key3 | value3 |
+---------------+--------------+

Model a(ributes
These named objects are usually called model a.ributes
+---------------+--------------+
| key1 | value1 |
+------------------------------+
| key2 | value2 |
+------------------------------+
| key3 | value3 |
+---------------+--------------+

Model implementa-ons
Several data structures can be used for represen2ng a model
• Any implementa-on of java.util.Map
• Any implementa-on of the Model interface provided by Spring
• A ModelMap object provided by Spring

Model as an input argument
Regardless the speciﬁc implementa2on, it is common prac2ce to let
the framework provide the model directly as an input argument
public String getGreeting(Map<String, Object> model) {...}
public String getGreeting(Model model) {...}
public String getGreeting(ModelMap model) {...}

Model as a Map
The only requirement when using java.util.Map to store model
a4ributes is that the key has to be of type String
public String getGreeting(Map<String, Object> model) {
model.put("greeting", greeting);
...
}

Model as a Map
The value part of the map can be freely decided. Because of its
generality, Object is a popular choice
public String getGreeting(Map<String, Object> model) {
...
}

Model as a Model
The downside of using a Map is that we have to decide the name of
each model a)ribute we want to store
// deciding names... boring (and difficult!)

Model as a Model
The Model interface provides convenient methods for popula4ng
the Model, such as addAttribute()
@RequestMapping("/special-deals")
public String getSpecialDeals(Model model) {
List<SpecialDeal> specialDeals = service.getSpecialDeals();
model.addAttribute(specialDeals);
...
}

Model as a Model
addAttribute() is the same as Map’s put(), except that it
automa&cally generates the name for the model a5ribute
@RequestMapping("/special-deals")
public String getSpecialDeals(Model model) {
List<SpecialDeal> specialDeals = service.getSpecialDeals();
model.addAttribute(specialDeals);
...
}

Naming strategy
• Scalar objects take the uncapitalized, unqualified class name
• Collec.on objects take the uncapitalized, unqualified class name
of the first object in the collec:on, with List appended to the
name

Naming strategy
Examples:
• com.myapp.Product becomes product
• List<com.myapp.Product> becomes productList

You can s)ll decide the names
If needed, it is s+ll possible to decide the name of each model
a4ribute
@RequestMapping("/fullname")
public String getFullname(Model model) {
// as both "Jon" and "Snow" are of type
// String, it is better to explicitly name them
model.addAttribute("name", "Jon");
model.addAttribute("surname", "Snow");
...
}

Model as ModelMap
The ModelMap class is a Map, but it provides some addi4onal
conveniences w.r.t. the plain Map interface
@RequestMapping("/fullname")
public String getFullname(Model model) {
// chained calls are handy!
model.addAttribute("name", "Jon")
.addAttribute("surname", "Snow");
...
}

Model as ModelMap
Namely:
• It adheres to the same naming conven2on as Model
• The addAttribute() method checks if the values are null
• It supports chained calls of the addAttribute() method

2. Taking care of the naviga2on logic

Choosing the next view
When processing is complete, the controller is responsible for
choosing what view the user sees next
+--------------+ +--------------------+ +----------------+
| | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | |
+--------------+ +--------------------+ +----------------+

The View renders the model
Views are responsible for rendering the objects in the Model
+--------------+ +--------------------+ +----------------+
| | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | |
+--------------+ +--------------------+ +----------------+

The View interface
Spring MVC does not make any assump)on on the speciﬁc view
technology
• JavaServer Pages
• JavaServer Faces
• Velocity

The View interface
To this end, views are modeled according to the View interface
public interface View {
void render(Map<String,?> model,
HttpServletRequest request,
HttpServletResponse response)
String getContentType();
}

The View interface
As with many Spring’s interfaces, the View interface is really simple
public interface View {
String getContentType();
}

The render() method
The View will render the output star2ng from
• The Model
• The Servlet’s request and response objects

The render() method
The render() method returns void to denote that it is the
arriving point of the en0re request processing pipeline7
7
Here, we are not considering possible calls to HandlerInterceptor.afterCompletion()

The render() method
Hence, it is the responsibility of the View not only to render the
content, but also to actually return it to the client

Wri$ng a View implementa$on
Given the interface, we can easily write a View implementa4on
public class GreetingView implements View {
@Override
public void render(Map<String, ?> model,
HttpServletResponse response) throws Exception {
PrintWriter out = response.getWriter();
out.print(model.get("greeting"));
out.flush();
out.close();
}
@Override
String getContentType() { ... }
}

View implementa*ons
However, most probably we would prefer to use a speciﬁc view
technology, rather than implemen9ng our own Views

View technology independence
Spring MVC makes a special eﬀort to keep the controller unaware
of the adopted view technology
public String getGreeting(Model model) {
...
return "greeting";
}

Such a decoupling is achieved by referring to views by their
logical name
...
return "greeting";
}

In order to enforce decoupling, we let the controller knows nothing
of the view but its logical name
...
return "greeting";
}

ViewResolver
The special bean ViewResolver will later resolve the view’s
logical name to an actual view instance
public interface ViewResolver {
View resolveViewName(String viewName, Locale locale);
}

ViewResolver
Implementa)ons of ViewResolver are able to provide the
mapping between logical names and View objects
+-----------------+
| |
| ViewResolver |
| |
+---+-----------^-+
| |
+---v----+ |
| View | |
+---+----+ |
| |
+-----v-----------+---+ +----------------+
| | | |
| DispatcherServlet <-------+ Controller |
| | | |
+---------------------+ +----------------+

getGreeting()
model.addAttribute("greeting", greeting);
return "greeting";
}

Controller testability
Note that this allows controllers to be easily unit-tested6
public class GreetingControllerTest {
@Test
public void getGreetingTest() {
GreetingController controller = new GreetingController(...);
Map<String, Object> model = new HashMap<>();
String viewName = controller.getGreeting(model);
assertTrue(viewName.equals("greeting"));
assertTrue(model.get("expression") != null);
}
}
6
Snippet adapted from h0p://stackoverﬂow.com/a/9363053/1849221

InternalResourceViewResolver
The most commonly used ViewResolver when developing with
JSP is the InternalResourceViewResolver

InternalResourceViewResolver obtains the psychical view
loca1on by surrounding the logical name with a preﬁx and a suﬃx

We need to conﬁgure InternalResourceViewResolver in
<bean class="org.springframework.web.
servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>

Hiding JSP pages
It is good prac-ce to place all view pages under the /WEB-INF
directory

Hiding JSP pages
This protects the pages from being retrieved independently of the
Controllers that conﬁgure them

References
• Stackoverﬂow, Design pa5erns for Web applica:ons
• SpringSource, Spring Framework Reference
• SpringSource, Java-doc APIs
• Stackoverﬂow, ModelMap usage in Spring

References
• S. Ladd, K. Donald, Expert Spring MVC and Web ﬂows, Apress
PublicaBons
• M. Deinum, K. Serneels, Pro Spring MVC: with Web ﬂows,
Apress PublicaBons
• Craig Walls, Spring in AcBon (3rd EdiBon), Manning PublicaBons
• T. N. Husted et al., Struts 1 In AcBon, Manning PublicaBons

References
• Clarence Ho, Rob Harrop, Pro Spring 3, Apress Publica8ons
• Rod Johnson et al., Professional Java Development with the
Spring Framework, Wiley Publishing

Spring MVC - The Basics

More Related Content

What's hot (16)

Viewers also liked (19)

Similar to Spring MVC - The Basics (20)

More from Ilio Catallo (20)

Recently uploaded (20)

Spring MVC - The Basics