MVC Architecture with Java EE

You now know how to write a servlet that handles a request and a JSP that renders HTML. A real application has thirty of each. The question that comes up then is no longer "how does it work" but "where do I put what" — and it's the one that decides whether your application will still be maintainable two years from now.

Field experience is unambiguous. Without discipline, logic spreads everywhere: a bit of SQL in a JSP, a discount calculation duplicated across three servlets, a business rule written inside a formatting tag. The day the VAT rate changes, you have to hunt for it across forty files. The day you want to expose the same data as JSON, you have to rewrite everything because the logic is inseparable from the HTML.

The Model-View-Controller pattern addresses this by assigning a single responsibility to each type of component. It is not a library to install: it is a division of labor that you impose on your code. In Jakarta EE, the mapping is direct — the servlet is the controller, the JavaBean is the model, the JSP is the view.

What you are going to build in this lesson, Spring MVC will later do for you. Assembling it by hand once is what makes Spring intelligible: when you see @GetMapping and Model, you will know exactly what mechanism is hidden behind them. A new project would start from Spring Boot; but someone who uses it without ever having written a front controller doesn't know what they are using.