Жизненный цикл SpringMVC-общий вид
Я новичок в Spring.
Я хочу проверить следующее понимание жизненного цикла SpringMVC - чтобы поместить вещи в места в общем представлении:
весь процесс управляется запросом.
есть шаблон переднего контроллера и передний контроллер весной MVC является DispatcherServlet.
на каждом входящем запросе от потребителя, Весна управляет весь жизненный цикл, как описано в здесь.
в целом, DispatcherServlet отправляет запрос контроллеру для службы в фоновом режиме. Как только это будет сделано, он передаст его компоненту View MVC для его представления, которое будет подготовлено в ответ на пользователя.
более подробно
DispatcherServlet использует обработчики, чтобы решить, "какой контроллер" для обслуживания этого запроса.
в регуляторы/должны быть "свет-утяжелены" -- должны быть отделены от процессы обслуживания на задней панели как хорошая практика проектирования - они содержат ссылки на службу(Ы) и вызывают правильный(ы). Их "миссия" контролировать процесс(ы) обслуживания для построения модели и вручать он вернулся к диспетчеру для следующего шага.
компонент View сам по себе имеет 2 части: сначала ViewResolver выбирает правильный тип поиска для просмотра, чтобы поместить модель в окончательный формат для пользователя.
с точки зрения разработчика -- DispatcherServlet-это закулисная вещь. Все, что я делаю, это определить и настроить его, если необходимо, в интернете.XML. Как разработчик, я создаю экземпляр ApplicationContext (существует много типов ApplicationContext-я выбираю один в зависимости от того, что мне нужно, обычно WebApplicationContext(?) ). AplicationContext-это фабрика, которая создает все сервлеты / бобы, включая в DispatcherServlet, используя их описания в.XML-файл. Затем DispatcherServlet запускается за кулисами и управляет весь процесс -- goes & получает контроллеры, используя аннотации или их .XML-описание, представления, обработчики, валидаторы и т. д.
Мне интересно, является ли это описание-действительным и полным, и есть ли в нем большие недостающие части.
спасибо заранее.
2 ответов
нет хорошего ответа на ваш вопрос. "Конечно" - это все, что я могу сказать.
вы можете настроить spring с помощью xml-файлов или аннотаций или комбинации обоих.
вам не нужно писать сервлеты с Spring MVC, но вы можете, если хотите. В основном вы можете (возможно, должны) создать классы контроллеров (либо путем расширения класса контроллера Spring, либо пометив класс аннотацией @Controller).
"миссия" контроллера заключается в выполнении необходимая обработка запросов. Они не просто "контролируют процессы обслуживания"
нет никакого "вернуть его" диспетчеру.
DispatchServlet должен быть настроен в интернете.XML-файл, это не опционально.
вы можете (возможно, должны) иметь слой между классами контроллера и любыми веб-службами, которые вы будете вызывать из классов контроллера.
вы можете иметь несколько applicationContexts или использовать один applicationContext.
Как часто как не, вид файла JSP.
контроллер должен добавить DTOs (объекты передачи данных), которые используются представлением для отображения нестатической информации. EDIT: я удалил упоминание объектов VO, я (как и многие, кажется) неправильно объединил шаблоны DTO и VO.
нет никакого "за кулисами". DispatcherServlet получает запрос и передает его соответствующему контроллеру для обработка.
прочитайте раздел 17 Spring Framework Reference
давайте подробно рассмотрим шаг за шагом
DispatcherServlet использует обработчики, чтобы решить, "какой контроллер" обслуживать эта просьба
на DispatcherServlet поддерживает упорядоченный List of HandlerMapping бобы (которые он загрузил из WebApplicationContext). А HandlerMapping is
интерфейс, который будет реализован объектами, определяющими отображение между запросы и обработчик объекты.
когда DispatcherServlet получает запрос, он выполняет итерацию по этому списку, пока не найдет соответствующий объект обработчика для рассматриваемого запроса. Для простоты, рассмотрим только RequestMappingHandlerMapping.
Боб этого типа хранит отображение @RequestMapping аннотированные методы (фактические Method объект, извлеченный с отражением) хранится как HandlerMethod экземпляры и завернутые в RequestMappingInfo объекты которые содержат данные сопоставления для соответствия запросу, т. е. URL, заголовки и параметры запроса.
на DispatcherServlet извлекает лучшее соответствие HandlerMethod из этих и каких-либо тегом HandlerInterceptor экземпляры, которые вы уже зарегистрированы. Он извлекает их как HandlerExecutionChain применяется пост-обработки на HandlerInterceptors. Он, наконец, обрабатывает результат отправки в зависимости от того, что это такое. вы можете увидеть поддерживаемые типы возврата для идеи, что это может быть.
регуляторы/должны быть "свет-утяжелены" -- должны быть decoupled от процессов обслуживания на задней части как хороший практика проектирования -- они содержат ссылки на службу(службы) и вызывают правильный(ые). Их "миссия" контролировать процесс(ы) обслуживания для построения модель и передача ее диспетчеру для следующего шага.
в приложении MVC контроллер управляет операциями, внося изменения в модель. Вы можете сделать это непосредственно в контроллере или отделить его, реализовав и предоставив сервис и бизнес-классы для этой цели. Этот контроллер зависит от них, но не наоборот. Проверьте многослойных архитектур.
контроллер затем строит модель (Model), который DispatcherServlet возможно делает доступным для просмотра. Я говорю, возможно, потому, что контроллер может производить ответ непосредственно без какого-либо представления (подумайте jsp) участвует.
компонент View сам по себе имеет 2 части: сначала выбирает ViewResolver правильный тип поиска вида, чтобы поместить модель в окончательный формат для пользователя.
в типичном случае, когда метод обработчика контроллера вернет Model, View, ModelAndView, String (и некоторые другие) объекта,ViewResolver будет обрабатывать поиск правильного View. The DispatcherServlet затем пытается отобразить это представление, сначала объединив модель, как вы сказали. Обычно это означает принимая все Model атрибуты и положить их в HttpServletRequest атрибуты. Шаг рендеринга может включать рендеринг a jsp, генерации XML или ничего вообще.
С точки зрения разработчика -- DispatcherServlet является закулисные дела. Все, что я делаю, это определяю и настраиваю его, если необходимо, в сети.XML. Как разработчик, я создаю экземпляр ApplicationContext (существует много типов ApplicationContext-- я выбираю один в зависимости от того, что мне нужно, обычно WebApplicationContext(?) ).
на самом деле вам не нужно создавать его экземпляр. The DispatcherServlet сделает это сам (или используйте ContextLoaderListenerс), когда Servlet контейнер называет init() на нем. Он будет генерировать свой собственный WebApplicationContext. что вы можете сделать, это решить, какой подкласс WebApplicationContext использовать. Это важный выбор, если вы хотите загрузить контекст из XML или из конфигурации Java. Вы можете сделать это предоставление <init-param>.
AplicationContext-это фабрика, которая создает все сервлеты / бобы включая DispatcherServlet, используя их описания в.XML файлы. Затем DispatcherServlet запускается за кулисами и управляет весь процесс-- goes & получает контроллеры, используя аннотации или их .xml-описания, представления, обработчики, валидаторы и т. д.
на ApplicationContext также известен как инверсия контрольного контейнера. Он не включает DispatcherServlet. The DispatcherServlet управляет Servlet контейнер и не к весне. Тем не менее, он в первую очередь берет свою конфигурацию из Spring's ApplicationContext (WebApplicationContext). он регистрирует ряд специальных бобов, которые он находит в контексте. вы можете объявить их сами или позволить Spring сделать это за вас с помощью этого маленького кусочка XML
<mvc:annotation-driven>
это (в основном) позаботится о том, что вы описываете, то есть. регистрировать обработчики, проверяющие, вид и т. д.
мне интересно, является ли это описание-действительным и полным, и есть ли в нем большие недостающие части.
не забывайте, что веб-приложение Spring MVC является Servlet веб-приложения. Таким образом, жизненный цикл приложения привязан к Servlet контейнер.