Spring MVC: The Ultimate Guide to HTTP Mastery from Bronze to King

“Spring MVC is not a tool for writing Controllers, but a guide on how to think in the paradigm of Web development.”

—— A note found in the notebook of an architect at Alibaba, P8 level

MVC stands for Model View Controller, which is a software design pattern. Its core principle is to separate business logic, data, and page presentation. This achieves a complete decoupling of protocol and business, allowing developers to focus entirely on business development.

Basic Understanding: How Spring Works

Core Components

  • <span>DispatcherServlet</span> Front Controller, responsible for receiving requests, dispatching them, and responding to clients. It acts as the central dispatcher for HTTP requests.
  • <span>HandlerMapping</span> Handler Mapper, which looks up the <span>Handler</span> by URL, and encapsulates the interceptors and <span>Handler</span> involved in the request into an execution chain. It serves as the routing navigator for requests.
  • <span>HandlerAdapter</span> Handler Adapter, which processes request data, performs parameter encapsulation, data validation, etc., adapting to execute the corresponding <span>Handler</span>.
  • <span>Handler</span> Request Processor, which handles the request and executes business logic.
  • <span>ViewResolver</span> View Resolver, which parses and renders the data returned by the <span>Handler</span> into a real view, and passes it to the <span>DispatcherServlet</span> to respond to the client (not needed in a decoupled front-end and back-end model).

Workflow

To understand the processing flow of Spring MVC, just remember the diagram below.

Spring MVC: The Ultimate Guide to HTTP Mastery from Bronze to King

Specific process description:

  1. The user initiates a request from the client, and the front controller receives the request.
  2. The front controller calls the handler mapper to find the handler.
  3. The handler mapper finds the corresponding handler based on the called URL, generates an execution chain, and returns it to the front controller.
  4. The front controller calls the handler adapter based on the returned execution chain: executing parameter encapsulation, data validation, etc.
  5. After the handler adapter processes the data, it calls the handler to execute the business logic, which is what we usually write in the Controller.
  6. After the handler completes the business logic, it encapsulates the data into ModelAndView and returns it.
  7. The handler adapter returns the ModelAndView to the front controller.
  8. The front controller hands the data over to the view resolver for parsing.
  9. The view resolver parses the data into a view and returns it to the front controller.
  10. The front controller hands the view over to the view for rendering.
  11. The view renders the data and returns it to the client.

As you may have noticed, I have framed the middle part of the diagram separately, excluding the view resolver and view sections, because in our current development, we are mostly using a decoupled front-end and back-end model, where the back-end is only responsible for returning data, and the front-end handles data rendering and presentation. Therefore, the view resolver and view parts (the yellow section in the diagram) are not used in the above process.

In a decoupled front-end and back-end model, the data format returned to the front controller is also not ModelAndView, but JSON format data.

In-Depth Understanding: The “Soul Question” of Spring MVC

❓ Question 1: Why is DispatcherServlet “stateless”?

Stateless means that the context required for processing each request is carried by the request itself, and the server responds independently based on the current request, without relying on previous interaction history. Its core feature is no correlation between requests.

  • The DispatcherServlet instance is a singleton, but each request is handled independently.
  • All state information (ModelAndView, Exception, etc.) is stored in the method stack, not in instance variables.
  • Resource cleanup is ensured through the <span>finally</span> block, ensuring complete thread safety.

💡 Design Essence:“Stateless front controller + Stateful request processing flow” ensures high concurrency performance while handling complex business logic.

❓ Question 2: Why is HandlerAdapter the “invisible heart” of MVC?

HandlerAdapter has three key functions:

  1. Converts HTTP requests into Java method calls;
  2. Converts HTTP request parameters into Java method parameters;
  3. Converts Java return values into HTTP responses.

It is through these three steps that the details of the HTTP protocol are hidden from us, allowing us to focus on implementing business functionality in Java. Additionally, by defining an adapter interface, we can easily extend it by adding corresponding adapter implementation classes. This achieves the design principle of <span>open for extension, closed for modification</span>.

Conclusion: The Ultimate Value of Spring MVC

Spring MVC is not a technology, but a way of thinking about web development.

It teaches us:

  • Protocols are implementation details; business is the core focus.
  • Good design should provide systematic extensibility, not temporary patches.
  • The value of a framework lies not in what it can do, but in how it allows you to forget its existence.

When you can:

  • See <span>@PathVariable</span> and think of <span>HandlerMethodArgumentResolver</span>
  • Consider how to implement new requirements through extension points first.
  • Explain to your team “why Spring MVC is more suitable for enterprise applications than using Servlets directly.”

Congratulations! You have transcended from a user to an understanding practitioner, which is more important than mastering any API.

Leave a Comment