Understand what MVC really means, how a web request actually travels through Spring, what DispatcherServlet is, why ViewResolver exists, and the difference between the two application contexts — all explained with zero jargon.
“Separating concerns so your code doesn't become a mess”
Customer (Browser) orders food → Waiter/Controller takes the order and coordinates → Chef/Service prepares the food using business rules → Store Room/DAO fetches the actual ingredients (data) → Plate/View is how the food is presented back to the customer.
Holds the data. In Spring MVC, the Model is a Map-like container that stores data to pass from Controller to View. It also refers to your Java domain objects (LoginBean, Employee, etc.).
Example: model.addAttribute("user", userObj)
Presents the data to the user. In classic Spring MVC, views are JSP files. The view receives data from the Model and renders HTML. The Controller decides which view to show — it never writes HTML itself.
Example: welcome.jsp displays the user's name from the model.
The coordinator. It receives HTTP requests, calls the Service layer to process business logic, puts results into the Model, and returns the name of the View to render. It's the traffic director.
Example: @Controller LoginController
🔑 Why MVC? Without MVC, one class would handle HTTP parsing, business logic, data access, AND HTML rendering — impossible to maintain. MVC divides responsibility so teams can work in parallel and code stays clean.
“The one servlet that controls everything”
DispatcherServlet is like an Airport Control Tower. Every plane (HTTP request) must communicate with the control tower first. The tower knows which runway (controller method) to direct each plane to, coordinates the landing, and directs the plane to the correct gate (view). No request bypasses the control tower.
HandlerMapping to find the right controller methodModelAndView returned by the controllerViewResolver to find the actual view fileurl-pattern / means DispatcherServlet handles ALL incoming requests.
DispatcherServlet is NOT the controller. It's the front controller — a design pattern where one class receives all requests and delegates them appropriately. Your @Controller classes are the actual controllers.
“What happens from the moment you press Enter in the browser?”
User types URL or submits a form. Browser sends GET or POST request to the server.
Since url-pattern is /, all requests go to DispatcherServlet first. It is the single entry point.
DispatcherServlet asks HandlerMapping: "Which controller method handles /login?" HandlerMapping scans @RequestMapping annotations and returns the correct method reference.
HandlerAdapter calls the controller method with the correct arguments (HttpServletRequest, Model, @PathVariable, @RequestParam etc.), handling all the messy parameter binding.
Controller calls Service → Service calls DAO → DAO queries DB. Results come back up the chain. Controller adds data to the Model and returns a View name string.
DispatcherServlet passes the view name (e.g., "welcome") to ViewResolver. ViewResolver converts it to the full file path: /WEB-INF/views/welcome.jsp
The JSP file accesses Model attributes and generates HTML. The HTML response is sent back to the browser.
“How a Java method becomes a web URL handler”
Maps a URL path + HTTP method to a Java method. Can be on the class level (base path) and method level (sub path). @GetMapping and @PostMapping are shortcut annotations for common cases.
String — View name to renderModelAndView — Combined model + view name"redirect:/url" — Redirect to another URL (browser changes URL bar)"forward:/url" — Internal forward (browser URL doesn't change)redirect: Server tells browser "go to this new URL". Browser makes a SECOND request. URL in address bar changes. Good for POST-Redirect-GET pattern to prevent form resubmission on refresh.
forward: Server internally forwards the request to another URL. Browser sees the same URL. Only one request.
“How Spring knows which controller method handles which URL”
HandlerMapping is like a telephone directory. When DispatcherServlet gets a request for /login, it asks HandlerMapping: "Who handles /login?" HandlerMapping looks up its directory (all @RequestMapping annotations) and returns: "That's LoginController.showLoginForm() for GET requests."
The most common HandlerMapping. It scans all @Controller classes at startup, reads @RequestMapping, @GetMapping, @PostMapping annotations, and builds an internal map of URL patterns to controller methods. When a request arrives, it looks up the URL in this map in milliseconds.
“Why do we return just 'login' and not the full path?”
Returning "login" from a controller is like giving a short code. ViewResolver is the translator that expands it. It has a prefix (/WEB-INF/views/) and a suffix (.jsp), so it converts "login" into /WEB-INF/views/login.jsp.
Why put JSPs under /WEB-INF/? Files under /WEB-INF/ cannot be accessed directly by the browser (it gets a 404). Only the server (via ViewResolver) can access them. This forces all requests to go through the Controller first — securing your views.
Why are JSPs placed in /WEB-INF/views/? Answer: So browsers cannot access JSP files directly, bypassing security and controller logic. Every view must go through the DispatcherServlet → Controller → ViewResolver chain.
“Why are there two Spring containers?”
Think of a company: Root Context = Head Office (has shared company-wide resources: HR, Finance, Shared DB). Servlet (Web) Context = Branch Office (has web-specific staff: Controllers, ViewResolver). Branch can use Head Office resources, but Head Office doesn't know about branch-specific web stuff.
Created by ContextLoaderListener. Contains shared beans: Services, DAOs, DataSource, JPA config, Transaction management. Any web component can access these beans.
Config file: applicationContext.xml
Beans inside: @Service, @Repository, DataSource, EntityManagerFactory, @Transactional setup
Created by DispatcherServlet. Contains web-specific beans: Controllers, ViewResolver, HandlerMapping, HandlerAdapter. It can access Root context beans (parent-child relationship).
Config file: [servlet-name]-servlet.xml (e.g., mvc-servlet.xml)
Beans inside: @Controller, ViewResolver, interceptors
Can a Service bean in Root context access a Controller bean in Servlet context? NO! Parent (Root) cannot access children (Servlet context). But a Controller in Servlet context CAN access Service beans from Root context. It's a one-way relationship: child sees parent, parent does NOT see child.
🔑 Why two contexts? Multiple DispatcherServlets can share the Root context. Each Servlet has its own isolated web context. This allows you to have different web layers (APIs, admin panel) sharing the same service/DAO layer.
“The classic way to configure Spring MVC”
What does <mvc:annotation-driven/> do? It registers RequestMappingHandlerMapping, RequestMappingHandlerAdapter, and message converters — everything needed to process @RequestMapping, @PathVariable, @RequestParam, @Valid, etc. Without this, most MVC annotations would be ignored.
“Same setup, but in pure Java code”
“How data gets from Java to the JSP page”
A container (like a Map) you add data to in your controller. Spring passes it to the view automatically.
Combines model data AND view name in one object. Less common with modern annotations but appears in older code.
Two uses: (1) On a method parameter — binds form data to a Java object automatically. (2) On a method — pre-populates model data before any controller method in the class runs.
“Spring MVC questions that always appear in interviews”
“Last-minute revision before your interview”