Главная » Spring » Создание веб-приложений  с  помощью Spring  MVC

0

Будучи разработчиком корпоративных приложений на языке Java, вам наверняка приходилось заниматься разработкой веб-при- ложений. Для многих разработчиков на Java создание веб-прило- жений является основным занятием. Если у вас есть подобный опыт, вы наверняка хорошо осведомлены о характерных проблемах, кото- рые приходится решать в подобных системах, таких как поддержка информации о текущем состоянии или проверка входных данных. И все они усугубляются еще больше независимой природой про- токола HTTP.

С целью помочь в решении всех этих проблем был разработан веб-фреймворк, входящий в состав Spring. Опираясь на шаблон модель–представление–контроллер (Model-View-Controller, MVC), фреймворк Spring MVC помогает строить веб-приложения, столь же гибкие и слабо связанные, как сам фреймворк Spring Framework.

В этой главе мы займемся изучением веб-фреймворка Spring MVC и новых аннотаций, сконструируем контроллеры, обрабаты- вающие веб-запросы. В процессе разработки мы будем стремиться проектировать веб-слой приложения в соответствии с архитекту- рой RESTful. В заключение посмотрим, как использовать теги JSP в представлениях, отправляемых пользователям в ответ на запросы.

Однако прежде чем углубляться в особенности реализации кон- троллеров и отображения запросов, окинем беглым взглядом фрейм- ворк Spring MVC и сконструируем простенькое веб-приложение.

Обзор Spring MVC

Видели ли вы когда нибудь детскую игру «Мышеловка»? Доволь- но забавная игра. Ее цель – провести небольшой стальной шарик в мышеловку через ряд хитрых приспособлений. Шарик катится через различные сложные конструкции, сначала по извилистой до- рожке через игрушечные качели на миниатюрное колесо обозрения, а потом подбрасывается из крошечного ведерка ударом резинового башмачка. И все только чтобы в конце защелкнуть в ловушке бед- ную, ничего не подозревающую пластмассовую мышку.

На первый взгляд создается ощущение, что фреймворк MVC Spring напоминает игру «Мышеловка». Только вместо перемещения шарика через различные желобки, качели и колеса Spring запутан- ными кругами перемещает запросы между сервлетом-диспетчером, механизмами отображения, контроллерами и представлениями.

Но не стоит слишком отождествлять Spring MVC с игрой «Мы- шеловка» в стиле Руби Голдберга. Каждый из компонентов в Spring MVC выполняет вполне конкретную задачу. Начнем изучение Spring MVC, ознакомившись с жизненным циклом типичного запроса.

Путь одного запроса через Spring MVC

Каждый раз, когда пользователь щелкает на ссылке или отправля- ет форму в веб-браузере, запрос отправляется на работу. Наш запрос работает курьером. Подобно почтальону или курьеру из службы до- ставки, запрос переносит информацию из одного места в другое.

Запрос – весьма занятой парень. С момента, когда он покинет брау- зер, и до момента, когда вернется ответ, запрос сделает несколько остановок, каждый раз сбрасывая часть информации и подбирая что- то взамен. На рис. 8.1 показаны все остановки, которые делает запрос.

Когда запрос покидает браузер, он несет в себе информацию о тре- бовании пользователя. По крайней мере, запрос будет нести в себе запрошенный URL. Но он может также нести дополнительные дан- ные, такие как информация из формы, заполненной пользователем.

Первой остановкой на пути запроса является DispatcherServlet.

Как и большинство веб-фреймворков на языке Java, фреймворк Spring MVC пропускает все входящие запросы через единственный сервлет входного контроллера. Входной контроллер (front controller) является типичным шаблоном проектирования веб-приложений, где

Рис. 8.1. Веб-слой приложения Spitter включает два контроллера ресурсов наряду

с несколькими вспомогательными контроллерами

единственный сервлет берет на себя ответственность за передачу всех запросов остальным компонентам приложения, выполняющим фактическую их обработку. В Spring MVC входным контроллером является   DispatcherServlet.

Задача контроллера DispatcherServlet состоит в том, чтобы пере- дать запрос контроллеру Spring MVC. Контроллер – это компонент Spring, обрабатывающий запрос. Но приложение может иметь не- сколько контроллеров, и входному контроллеру DispatcherServlet требуется помощь, чтобы определить, какому контроллеру пере- дать запрос. Поэтому контроллер DispatcherServlet консультируется c одним или несколькими механизмами отображения и выясняет, где будет следующая остановка запроса. При принятии решения механизм отображения в первую очередь руководствуется адресом URL в запросе.

Как только будет выбран соответствующий контроллер, Dispatcher- Servlet отправляет запрос в путь к выбранному контроллеру. До- стигнув контроллера, запрос отдаст часть своего груза (информа- цию, отправленную пользователем) и терпеливо будет ждать, пока контроллер обработает эту информацию. (На самом деле хорошо спроектированный контроллер сам почти не занимается обработкой информации, вместо этого он делегирует ответственность за обра- ботку одному или нескольким служебным объектам.)

В результате работы контроллера часто появляется некоторая информация, которая должна быть передана назад пользователю и отображена в браузере. Эта информация называется моделью. Но

отправки обратно необработанной информации недостаточно, перед отправкой ее следует представить в удобном для пользователя фор- мате, обычно в HTML. Для этого информация должна быть пере- дана в одно из представлений, которыми обычно являются JSP.

Последнее, что должен сделать контроллер, – упаковать вместе модель и имя представления для отображения результатов в брау- зере. Затем он отсылает запрос вместе с моделью и именем пред- ставления обратно входному контроллеру DispatcherServlet.

Чтобы контроллер не оказался тесно связанным с каким-либо конкретным представлением, имя представления, возвращаемое входному контроллеру DispatcherServlet, не определяет JSP-страницу непосредственно. Фактически оно даже не предполагает, что пред- ставление вообще является страницей JSP. Оно является лишь ло- гическим именем представления, используемым затем для поиска фактического представления. Чтобы отобразить логическое имя представления в ссылку на конкретную реализацию, входной кон- троллер DispatcherServlet обратится к арбитру представлений (view resolver).

Теперь, когда контроллер DispatcherServlet определил, какое пред- ставление будет отображать результаты, работа запроса подошла к концу. Его конечная остановка – реализация представления (воз- можно, страница JSP), куда он доставит модель данных. На этом работа запроса заканчивается. На основе модели данных представ- ление создаст отображение страницы, которое будет отправлено об- ратно клиенту с другим (не таким трудолюбивым) курьером – объ- ектом ответа.

В этой главе мы подробно рассмотрим каждый из этих эта- пов. Но сначала необходимо настроить Spring MVC и компонент DispatcherServlet.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии