Introduction to Spring MVC

Writing a Java web application without a framework is an instructive exercise, and nobody does it twice. You have to declare one servlet per screen, read the parameters by hand from HttpServletRequest, convert them from strings, check that they are not missing, decide what to do when the conversion fails, choose a status code, and then write the HTML character by character into the output stream. The business code — the three lines that really matter — gets drowned in this plumbing, and the plumbing is rewritten for every screen.

The problem isn't the amount of code. It's that this repetitive code is decision-making code. Each servlet decides on its own how to interpret the request, how to signal an error, and how to produce its response. After thirty screens, an application contains thirty slightly different conventions, and the smallest cross-cutting change — adding a log trace, enforcing a date format, handling errors uniformly — turns into a treasure hunt across thirty files.

Spring MVC answers this with a reversal: instead of letting each screen fend for itself, a single servlet receives all of the application's requests and orchestrates how they are handled. This servlet knows nothing about your business logic; it only knows how to identify the piece of code responsible for a URL, give it parameters that are already converted and validated, and then turn its return value into an HTTP response. Your job is then reduced to writing Java methods that receive objects and return objects.