Spring MVC

1.

Spring MVC
astondevs.r
u

2. Spring MVC

Spring MVC – Это модуль spring, который позволяет писать веб приложения с использованием
паттерна MVC.
● Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё
состояние.
● Представление (View) отвечает за отображение данных модели пользователю, реагируя на
изменения модели.
● Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о
необходимости изменений.
Главной целью Spring MVC является разделение объектов, бизнес-логики и внешнего вида
приложения. Все эти компоненты слабо связаны между собой и при желании мы можем
изменить, например, внешний вид приложения, не внося существенные изменения в
остальные два компонента.

3. Model

• Модель (Model) – В Spring MVC модель работает, как контейнер для объектов, которые
используются при рендеринге view. Т.е. мы кладем в модель какие-то данные и они будут
доступны во view.
• Модель является бином с request scope.
• Концептуально модели можно рассматривать, как мапы.
• Есть 3 основные, независимые иерархии моделей:
1. interface Model
2. class ModelMap
3. class ModelAndView

4. View и ViewResolver

Представление (View) - Модуль представления отвечает за вывод данных пользователю.
Обычно это JSP файл, который может быть опознан и интерпретирован браузером на
пользовательской машине.
View это по сути бины, которые на вход принимают модель с атрибутами, на выходе отдает
html.
ViewResolver позволяет зарезолвить (определить) конкретную вью по имени и локали. В этом
интерфейсе определен единственный метод

5. Controller

Контроллер (Controller) - отвечает за обработку запросов пользователей и передачу данных модулю View для
обработки.
Чаще всего работа контроллера будет выглядеть
следующим образом

6. Request handling workflow

Вся логика работы Spring MVC построена вокруг DispatcherServlet, который принимает и обрабатывает все HTTP-запросы и
ответы на них.

7.

Request handling workflow
1. DispatcherServlet является реализацией паттерна front controller. Суть которого заключается
в том, чтобы принимать все запросы, делегировать их выполнение другим модулям и
отдавать ответ потребителям.
2. После получения HTTP-запроса DispatcherServlet обращается к интерфейсу HandlerMapping,
который определяет, какой Контроллер должен быть вызван, после чего, отправляет запрос
в нужный Контроллер.
Одна из реализаций HandlerMapper из коробки мапит метод запроса и uri к конкретному
контроллеру.
3. Контроллер принимает запрос и вызывает соответствующий служебный метод. Вызванный
метод определяет данные Модели, основанные на определённой бизнес-логике и
возвращает в DispatcherServlet имя Представления(View).
4. При помощи интерфейса ViewResolver DispatcherServlet определяет, какое Представление
нужно использовать на основании полученного имени.
5. После того, как Представление(View) создано, DispatcherServlet отправляет данные Модели в виде атрибутов
в Представление, которое в конечном итоге отображается в браузере.

8.

Request handling workflow

9.

HandlerInterceptor
Перед вызовом контроллера, запрос проходит через цепочку HandlerInterceptor’ов.
Данные интерсепторы позволяют получить доступ к request/respons:
• До того, как они попадут к контроллеру
• После того, как контроллер отработал
• После того, как view будет зарендерено

10.

HandlerInterceptor vs Filter
Фильтры перехватывают request/response до того, как они попадут в DispatcherServlet. Фильтры можно
использовать для любой промежуточной обработки: Логирование, авторизация, любые операции, которые мы
хотим отвязать от Spring MVC.
HandlerIntercepors перехватывают request/response до того, как они попадут в контроллер. Это происходит в
рамках Spring MVC, поэтому у HI помимо request/response есть доступ к Handler and Model объектам.
Концептуально подходят для таких же cross-cutting операций, что и фильтры + могут что-то делать с
Handler and Model.

11. Request handling workflow

12. Contexts

Прежде чем переходить к контекстам, необходимо знать, что Spring может иметь несколько контекстов, один из них будет
родительским контекстом (root context), другой дочерним (child context). Все дочерние контексты имеют доступ к бинам,
расположенным в родительском контексте, но не наоборот.
Когда мы пишем Spring MVC приложения, у нас появляется множество бинов из коробки (HandlerMapping, ViewResolver и
тд), все они находятся в дочернем контексте. Каждый DispatcherServlet прогружает свой контекст (Обычным приложениям
хватает одного DispatcherServlet’a).
DISCLAIMER!
Вы можете иметь один root контекст, в случае
если у вас простое веб приложение с одним
DispatcherServlet.

13.

Полезные ссылки для понимания контекстов:
https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet/context-hierarchy.html
https://www.baeldung.com/spring-web-contexts
https://stackoverflow.com/questions/18682486/why-does-spring-mvc-need-at-least-two-contexts