How Spring MVC Simplifies Server‑Side Development: From Servlets to DispatcherServlet

Spring MVC originated from the need to simplify server‑side development beyond the basic Servlet API. This article reviews the evolution from plain Servlets, their limitations, and how Spring MVC introduces a front‑controller (DispatcherServlet) and a two‑level controller architecture to handle requests, map them to handlers, apply interceptors, and render views.

1. Former King—Servlet

Early Java web development relied on raw Servlets, which required manual handling of request parsing, response generation, and configuration in web.xml. Servlets encapsulate request and response objects ( HttpServletRequest, HttpServletResponse) and follow a template‑method pattern.

Network programming inevitably involves Socket . HTTP/HTTPS sit on top of sockets, providing a unified API. HttpServlet wraps the request into HttpServletRequest and the response into HttpServletResponse , freeing developers from low‑level network code.

Using a Servlet typically involves three steps:

Create a class extending HttpServlet and override doGet() and doPost() to process HttpServletRequest and produce HttpServletResponse.

The Servlet follows the template‑method pattern: the container calls service(), which delegates to the overridden doXXX() methods.

Register the Servlet in web.xml with a servlet-mapping to define the URL it handles.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
          version="2.4">
    <servlet>
        <servlet-name>ShoppingServlet</servlet-name>
        <servlet-class>com.myTest.ShoppingServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>ShoppingServlet</servlet-name>
        <url-pattern>/shop/ShoppingServlet</url-pattern>
    </servlet-mapping>
</web-app>

2. Want to go further

Each Servlet handles only one request, leading to a proliferation of classes in large systems.

Developers must manually extract parameters, validate them, invoke services, and decide between forward or redirect.

URL mappings are hard‑coded in web.xml, lacking flexibility.

Servlets are tightly coupled with the view technology, making UI changes painful.

To address these issues, developers created a BaseServlet that uses a method request parameter to invoke specific methods via reflection, returning a view name for forwarding or redirecting.

3. Spring MVC—Two‑level controller

Spring MVC renames the “super servlet” as DispatcherServlet , acting as a front‑controller. Business‑logic classes are called Handlers (commonly implemented as Controllers). The original BaseServlet concept maps to DispatcherServlet, while the custom Servlet becomes a Handler.

4. DispatcherServlet—Front Controller

DispatcherServlet orchestrates the entire request lifecycle: it receives all requests, delegates to HandlerMapping to locate a Handler, builds a HandlerExecutionChain, invokes any HandlerInterceptor s, executes the Handler, and finally uses a ViewResolver to render the response.

5. HandlerMapping—Request mapping expert

Spring provides several HandlerMapping implementations to associate URLs with Handlers: SimpleUrlHandlerMapping – explicit URL‑to‑Handler configuration. ControllerClassNameHandlerMapping – derives the URL from the Controller class name. BeanNameUrlHandlerMapping – uses the bean name as the URL. DefaultAnnotationHandlerMapping – leverages @RequestMapping annotations (the most common today).

6. HandlerInterceptor—Interceptor chain

Before a Handler executes, one or more HandlerInterceptor s can intercept the request, performing tasks such as authentication, logging, or error handling. Unlike Servlet Filter, an interceptor works at the Handler level, offering finer granularity.

7. Handler—Business logic

Handlers (or Controllers) contain the actual business code. They receive data from services, place it into a ModelAndView, and return the logical view name.

8. HandlerExecutionChain—Bridge

HandlerExecutionChain

bundles a Handler with its associated Interceptors, forming a responsibility‑chain. The request passes through each Interceptor; if any returns false, processing stops.

9. ModelAndView—Decoupling key

ModelAndView

carries both the model data and the logical view name, separating business processing from view rendering.

10. ViewResolver—View lookup

Spring resolves the logical view name to an actual view implementation. Common resolvers include:

BeanNameViewResolver

XmlViewResolver

InternalResourceViewResolver (JSP)

FreeMarkerViewResolver

VelocityViewResolver

JasperReportsViewResolver

XsltViewResolver

11. View—Data rendering

The selected View renders the model data (e.g., JSP, FreeMarker, Velocity) and returns the final HTML to the client via DispatcherServlet.

The complete Spring MVC flow is illustrated below:

That concludes the overview of Spring MVC’s request processing mechanism.