In the first chapter, we were introduced to the dispatcher servlet and saw how to define a dispatcher servlet in web.xml. We learned that every web request first comes to the dispatcher servlet. The dispatcher servlet is the one that decides the controller method that it should dispatch the web request to. In the previous chapter, we created a welcome page that will be shown whenever we enter the URL http://localhost:8080/webstore/ on the browser. Mapping a URL to the appropriate controller method is the primary duty of a dispatcher servlet.

So the dispatcher servlet reads the web request URL and finds the appropriate controller method that can serve that web request and invokes it. This process of mapping a web request to a specific controller method is called request mapping, and the dispatcher servlet is able to do this with the help of the @RequestMapping annotation (org.springframework.web.bind.annotation.RequestMapping).

Let's observe what will happen when you change the value attribute of the @RequestMapping annotation by executing the following steps:

In a Spring-based application, our application objects live within an object container. This container creates objects and associations between objects, and manages their complete life cycle. These container objects are called Spring-managed beans (or simply beans), and the container is called an application context in the Spring world.

A Spring container uses dependency injection (DI) to manage the beans that make up an application. An application context (org.springframework.context.ApplicationContext) creates beans and associate beans together based on the bean configuration and dispenses beans on request. A bean configuration can be defined via an XML file, annotation, or even via Java configuration classes. We will use only XML- and annotation-based bean configurations in our chapters.

A web application context is the extension of an application context, designed to work with the standard servlet context (javax.servlet.ServletContext). A web application context...

You have received enough of an introduction on the web application context; now, tweak a little bit with the name and location of the web application context configuration file (DefaultServlet-servlet.xml) and observe the effect. Perform the following steps:

The web application context configuration file (DispatcherServlet-context.xml) is nothing but a simple Spring bean configuration file. Spring will create beans (objects) for every bean definition mentioned in this file during bootup of our application. If you open this web application context configuration file (/WEB-INF/spring/webcontext/DispatcherServlet-context.xml), you will find some configuration and bean definition as follows:

<?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="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4...

We saw the purpose of the first two tags that are specified within the web application context configuration file:

<mvc:annotation-driven />
<context:component-scan base-package="com.packt.webstore" />

Based on these tags, Spring creates the necessary beans to handle a web request and also creates beans for all the @Controller classes. However, to run a Spring MVC application successfully, Spring needs one more bean; this bean is called a view resolver.

A view resolver helps the dispatcher servlet identify the views that have to be rendered as the response for a specific web request. Spring MVC provides various view resolver implementations to identify views, and InternalResourceViewResolver is one such implementation. The final tag in the web application context configuration is the bean definition for the InternalResourceViewResolver class as follows:

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix...

We instruct Spring to create a bean for an InternalResourceViewResolver class, but why? Who is going to use this bean? What is the role of the InternalResourceViewResolver bean in Spring MVC? Find the answer to these questions through the following exercise:

So far, we have seen lots of concepts, such as the dispatcher servlet, request mapping, controllers, and view resolver; it would be good to see the overall picture of the Spring MVC request flow so that we can understand each component's responsibilities. However, before that, we need to understand the Model View Controller (MVC) concept some more. Every enterprise-level application's presentation layer can logically be divided into the following three major parts:

The following diagram will help you understand the event flow and command flow within an MVC pattern:

The classic MVC pattern

Whenever a user interacts with the view by clicking on a link or button, the view issues an event notification to the controller, and the controller issues a command notification to the model to update...

The main entry point for a web request in a Spring MVC application is via the dispatcher servlet. The dispatcher servlet acts as the front controller and dispatches the requests to the other controller. The front controller's main duty is to find the appropriate controller to hand over the request for further processing. The following diagram shows an overview of the request flow in a Spring MVC application:

The Spring MVC request flow

Now, let's review the Spring MVC request flow in short:

Now, we understand the overall request flow and responsibility of each component in a typical Spring MVC application. However, this is not enough for us to build an online web store application. We also need to know the best practices to develop an enterprise-level web application. One of the best practices in a typical web application is to organize source code into layers, which will improve reusability and loose coupling. A typical web application normally has four layers: the presentation, domain, services, and persistence. So far, whatever we have seen, such as the dispatcher servlet, controllers, view resolvers, and so on, is considered a part of the presentation layer components. Let's understand the remaining layers and components one by one.

Let's start with the domain layer. A domain layer typically consists of a domain model. So, what is a domain model? A domain model is a representation of the data storage types required by the business logic. It describes the various domain objects (entities); their attributes, roles, and relationships; plus the constraints that govern the problem domain. Take a look at the following domain model diagram for order processing to get a quick idea about the domain model:

Sample domain model

Each block in the preceding diagram represents a business entity, and the lines represent the associations between the entities. Based on the preceding domain model diagram, we can understand that, in an order processing domain, a customer can have many orders, each order can have many order items, and each order item represents a single product.

During coding, the domain model will be converted into corresponding domain objects and associations by a developer. A domain object is a logical...

So far, in your webstore, you have showed only a welcome message. It is now time for you to show your first product on the web page. Do this by creating a domain object, as follows, to represent the product information: