Я знаю, что этот вопрос помечен как уже решенный, но я хочу добавить более новое изображение, подробно объясняющее этот паттерн (источник: spring in action 4):
Объяснение
Когда запрос покидает браузер (1) , он содержит информацию о том, что запрашивает пользователь. По крайней мере, запрос будет содержать запрошенный URL. Но он также может содержать дополнительные данные, например информацию, представленную пользователем в форме.
Первая остановка в запросах - в DispatcherServlet Spring. Как и большинство веб-фреймворков на основе Java, Spring MVC направляет запросы через один сервлет фронт-контроллера. Фронт-контроллер - это общий шаблон веб-приложения, в котором один сервлет делегирует ответственность за запрос другим компонентам приложения для выполнения фактической обработки. В случае Spring MVC DispatcherServlet является фронт-контроллером.
Задача DispatcherServlet - отправить запрос на контроллер Spring MVC. Контроллер - это компонент Spring, который обрабатывает запрос. Но типичное приложение может иметь несколько контроллеров, и DispatcherServlet нужна помощь, чтобы решить, на какой контроллер отправить запрос. Таким образом, DispatcherServlet обращается к одному или нескольким сопоставлениям обработчиков (2) , чтобы выяснить, где будет следующая остановка запроса. При сопоставлении обработчик обращает особое внимание на URL-адрес, передаваемый запросом.
Как только соответствующий контроллер был выбран, DispatcherServlet отправляет запрос на своем веселом пути выбранному контроллеру (3) . На контроллере запрос сбрасывает свою полезную нагрузку (информацию, представленную пользователем) и терпеливо ждет, пока контроллер обработает эту информацию. (На самом деле, хорошо спроектированный контроллер сам выполняет незначительную обработку или не выполняет ее и вместо этого передает ответственность за бизнес-логику одному или нескольким объектам службы.)
Логика, выполняемая контроллером, часто приводит к некоторой информации, которую необходимо передать обратно пользователю и отобразить в браузере. Эта информация называется моделью. Но отправка необработанной информации обратно пользователю недостаточна - ее необходимо отформатировать в удобном для пользователя формате, обычно в HTML. Для этого информация должна быть передана в представление, обычно на страницу JavaServer (JSP).
Одна из последних вещей, которые выполняет контроллер, - упаковывает данные модели и идентифицирует имя представления, которое должно отображать выходные данные. Затем он отправляет запрос вместе с именем модели и вида обратно в DispatcherServlet (4) .
Чтобы контроллер не был связан с конкретным представлением, имя представления, переданное обратно в DispatcherServlet, напрямую не идентифицирует конкретную JSP. Это даже не означает, что представление является JSP. Вместо этого он несет только логическое имя, которое будет использоваться для поиска фактического представления, которое будет давать результат. DispatcherServlet обращается к преобразователю представлений (5) , чтобы сопоставить имя логического представления с конкретной реализацией представления, которая может быть или не быть JSP.
Теперь, когда DispatcherServlet знает, какое представление будет отображать результат, работа запроса почти завершена. Его окончательная остановка - реализация вида (6) , обычно JSP, куда он доставляет данные модели. Работа с запросом окончательно выполнена. Представление будет использовать данные модели для визуализации вывода, который будет возвращен клиенту (не очень трудоемким) объектом ответа (7) .