Введение в Spring Frameworks: Spring MVC

[iMate]

Мне кажется, что пример со сложением двух чисел с помощью Spring не показывает преимущества использования этого фреймворка. Читать статью становится скучновато… Как-будто на первом уроке по микроскопии предложили забивать гвозди :)

[StMechanus]

Я хотел предложить максимально простой пример, который не вызвал бы вопросов. Вероятно нужно было привести более серьезных пример. Хотя я сам начинал изучение Spring с книги «Spring 3 для профессионалов» и там приводился пример с всеми любимым «Hello World», что после изучения примера вызвало у меня вопрос: а зачем такие сложности?.. Хотя спустя несколько глав эти вопросы отсеялись, когда начались реальные упрощения жизни. Думаю, что без таких банальных примеров в самом начале никуда, так сказать нужно углубляться постепенно =)

[Zapletnev]

Это моя первая статья.Прошу сильно молотком не бить.

Именно так проливается кровь

[4y4z]

Для старта лучше воспользоваться туториалом с официального сайта сообщества Spring — описывается создание серьезного веб-приложения с использованием возможностей Spring. Имхо, так гораздо проще понять преимущества Spring и сферу его применения. Стоит также обратить внимание на книгу Spring in Action (3-е издание вполне актуально) — можно и как справочник готовых решений использовать, и как хороший учебник, раскрывающий философию Spring.

[StMechanus]

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

[4y4z]

Ну так если изучать один стиль, то может все-таки брать за основу то, что рекомендуют сами разработчики фреймворка?

[solver]

1. Название статьи «Введение в Spring Frameworks». А вся статья исключительно про Spring MVC.
2. Ни слова вообще что такое Spring Frameworks, области применения и т.д.
3. Очень мало инфы. Фактически это банальная инструкция как создать простейшее приложение парой кнопок из IDE.

Т.е. это вообще никакое не введение куда бы то ни было.
Это банальная инструкция как создать в конкретной IDE проект Spring MVC. Такой инфы в инете вагон и маленькая тележка.

[StMechanus]

Следущая статья будет более информативной с точки зрения теории, обещаю)

[solver]

У большинства проблема вообще понять, когда нужен Spring Frameworks и где его можно применять.
При этом основная проблема это IoC. Понять в каких случаях это облегчает разработку, а в каких оверхед.
А пошаговых инструкций «как создать проект» в инете полно.

[javax]

Главное в спринге — Dependency Injection а о нем не слова

[norguhtar]

Приступим к созданию конфигурации. Я приведу сразу готовый конфигурационный класс и ниже опишу все необходимые детали.

По пальцам молотком не хотите? Зачем вы кладете конфигурацию в компилированный класс? Он отлично кладется в конфигурацию spring в xml. В этом вся прелесть. Да аннотации позволяют положить конфигурацию в класс, но делать этого не надо. По простой причине, если вам потребуется что-то поменять, то вам придется пересобирать класс. Лучше положить в xml к примеру ваша конфигурация будет выглядеть так:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:context="http://www.springframework.org/schema/context"
        xmlns:mvc="http://www.springframework.org/schema/mvc"
        xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.1.xsd
                http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
                http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">

       <!-- Scans within the base package of the application for @Components to configure as beans -->
       <context:component-scan base-package="com.springapp" />

        <!-- Configures support for @Controllers -->
        <mvc:annotation-driven conversion-service="conversionService"/>

    <bean id="conversionService"
          class="org.springframework.format.support.FormattingConversionServiceFactoryBean"/>

        <!-- Resolves view names to protected .jsp resources within the /WEB-INF/views directory -->
    <bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix" value="/WEB-INF/views/"/>
        <property name="suffix" value=".jsp"/>
    </bean>

Как вы видите это можно будет изменять уже после того как приложение собрано. И это важно так-как к примеру позволяет добавлять еще представления кроме JSP. К примеру для генерации docx через свой view

Дополнительно отмечу, что лучше при использовании spring начинать с STS среды которую делают авторы Spring Framework.

[jakobz]

Т.е. стоит такой сервак в проде, а ты такой — шаблонный движок что-ли поменять?

[norguhtar]

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

[jakobz]

Сам я дотнетчик, и у нас, было, тоже с явы моду стянули писать всё на XML. Но сейчас вроде отлегло, что не может не радовать — динамическая перезагрузка приложения никак не перевешивает необходимость писать на XML вместо человеческого языка.

[norguhtar]

Я уже ниже доводы свои писал. И не считаю хорошим тоном размещать стандартные настройки в код. И да в spring в xml километры параметров как было в JEE5 не требуется. Как кстати уже и в JEE7

[StMechanus]

У нас была долгая дискуссия на тему, как же будет лучше: применять только XML или только аннотации. Свелось все к тому, что лучше применять только аннотации так как:
1) Хорошо читается
2) Удобно сопровождать
3) Легко передавать другому сотруднику на сопровождение

Хотя в некоторой степени вы правы, в xml есть свои плюсы, однако необходимость их использования бывает крайне редко. Но опять таки — это дело вкуса и привычки.

[norguhtar]

Стоит использовать аннотации где они уместны и понятно какой функционал за ними стоит. К примеру для entity в JPA уместно, для указания тут контроллер уместно. А вот для настройки стандартных компонентов Spring MVC как-то не уместно. Так-как этот класс используется ровно один раз для чтения аннотаций при инициализации.

[StMechanus]

Эта дискуссия в принципе ни к чему не приведет. У вас все также будет свое мнение по этому поводу, а у меня свое. Но тем не менее я учту вашу точку зрения. Рассказывая про data-jpa я приведу пример и с xml и без него, а там пусть каждый выбирает для себя, что ему более интересно ;)

[norguhtar]

Ну вот в data-jpa точно не стоит xml использовать ;)

[soir]

Не соглашусь. Сам привык конфигурировать бины в Спринге в XML файлах, но если приложение задеплоено в веб-сервер в виде WAR файла, то не полезете же вы редактировать этот XML прямо внутри архива? А коли так, то нет никакой разницы описывать бины в XML или в классе конфигурации, все равно билдить новый WAR.

[norguhtar]

Давайте уж код отдельно конфигурация отдельно. Ну не имеет смысла никакого этот класс.

[soir]

Давайте для начала договоримся:
конфигурация, в моем понимании, в простейшем случае, это *.properties файлы в которых лежат конфигурационные параметры приложение. XML файлы с описанием зависимостей между Spring бинами, в моем понимании, не являются конфигурацией приложения, это такой же код, только в виде XML.

[norguhtar]

Не соглашусь. Код это все же то что мы пишем на языке java. Тут же это как раз конфигурация которую spring-framework читает при инициализации и раскладывает по своим стандартным компонентам. Именно по этой причине написание класса для конфигурации тут избыточно. У вас фактически класс используется для хранения строк и больше не для чего.

[anjensan]

По пальцам молотком не хотите? Зачем вы кладете конфигурацию в компилированный класс?

Скажите это ребятам из Google, авторам guice. Вот уже где дураки работают, да?

[norguhtar]

из FAQ guice

How do I load configuration properties?
Use Names.bindProperties() to create bindings for each of the properties in a configuration file.

Так что вы там говорили про ребят из гугла?

[anjensan]

А ничего, что Names.bindProperties кушает property-файлы и Map<String,String>?
Как-бы предназначено это исключительно для настроек: пути к файлам, имена серверов, порты и т.п. Структура приложения, имена классов, что куда биндится, какие бины на какие ссылаются, иерархия модулей и прочее задается в Java-коде.

Собственно, sov уже писал вам, процитирую:

конфигурация, в моем понимании, в простейшем случае, это *.properties файлы в которых лежат конфигурационные параметры приложение. XML файлы с описанием зависимостей между Spring бинами, в моем понимании, не являются конфигурацией приложения, это такой же код, только в виде XML.

[norguhtar]

А ничего, что Names.bindProperties кушает property-файлы и Map<String,String>?

Эм, а что я рекомендую класть в xml не строка?

Как-бы предназначено это исключительно для настроек: пути к файлам, имена серверов, порты и т.п. Структура приложения, имена классов, что куда биндится, какие бины на какие ссылаются, иерархия модулей и прочее задается в Java-коде.

Эм. Вообще в приведенном коде задается только одна такая специфичная как вы описали настройка. С какого namespace осуществлять сканирование. А вот настройка где лежат jsp и какой ресолвер будет использоваться отлично укладывается в описанную вами концепцию. Так что ладно еще вот это

 <context:component-scan base-package="com.springapp" />

        <!-- Configures support for @Controllers -->
        <mvc:annotation-driven conversion-service="conversionService"/>

Можно разместить в код

А вот это

   <bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix" value="/WEB-INF/views/"/>
        <property name="suffix" value=".jsp"/>
    </bean>

Явно нет.

[anjensan]

Вы указываете имена классов в коде явно? А имена пакетов? Так какая разница между именем пакета (что по своей сути есть относительный путь к файлам) и путем "/WEB-INF/views"? Эти файлы лежат в скомпилированном war-файле, у них жестко заданный путь и расширение — после деплоя не может (не должна!) возникнуть необходимость менять эти параметры.

[norguhtar]

Так какая разница между именем пакета (что по своей сути есть относительный путь к файлам) и путем "/WEB-INF/views"?

В том что это путь до файлов. И да между прочим в war файле есть такой замечательный файл web.xml. И как-то ничего жить никому он не мешает. Хотя вот по вашей логике его быть там не должно.

Эти файлы лежат в скомпилированном war-файле, у них жестко заданный путь и расширение — после деплоя не может (не должна!) возникнуть необходимость менять эти параметры.

У вас между прочим properties файлы с

Как-бы предназначено это исключительно для настроек: пути к файлам, имена серверов, порты и т.п.

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

[anjensan]

Вы начинаете придумывать. Никто Вам не говорил, что не должно быть xml-файлов, конфигов, мол все нужно размещать в коде.

У вас между прочим properties файлы с… тоже лежат в нем. И тоже не изменяемый.

Простите, но опять фантазии. Эти файлы могут лежать где угодно, и это определяется уже процедурой деплоя.

Как-то я считаю что настройки стоит класть в файл, а не в код.

Да, полностью поддерживаю!

И описание какой будет использован view это именно настройка.

А вот тут наши мнения расходятся. Я придерживаюсь вышеназванного мнения (приводил цитату).

Никто никому не запрещает использовать xml вместо аннотаций. Другой вопрос, что при этом все равно следует разносить непосредственно настройки и структуру приложения. Как этого достигнуть — отдельный вопрос. Можно использовать несколько xml-файлов. Можно использовать property-файлы. Можно при деплое генерировать конечный xml на основе шаблона (в котором используются шаблонные параметры аля $paramname). Вариантов же много.

Представте, что периодически обновляете версию приложения на сервере. При этом, разумеется, постепенно изменяется его структура. Появляются новые бины, старые уходят в небытие. Изменяются связи между ними. Но при этом параметры подключения к БД не меняются, имена серверов остаются прежними.

Структуру приложения нужно обновлять синхронно с кодом. Параметры приложения нет (ну, разумеется, следует своевременно добавлять новые). Пэтому их в любом случае следует разносить, как минимум ради удобства. Но раз мы обновляем структуру приложения синхронно вместе с кодом, то почему бы ее переместить в этот самый код?

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

[norguhtar]

Что-то мне не кажется что указывать какие представления будут использованы удобно в коде. Как минимум это порождает еще один лишний класс заглушку, который уже есть в spring. По этой причине и считаю что заметно проще и удобнее положить это в xml файл, а не тащить за собой в приложение. Опять же если смотреть официальную документацию по Spring Framework то в нем настройку view размещают в xml файл. И стоит придерживаться этого умолчания. Так-как конечно другой программист найдет где это лежит, но рад не будет.

[perl_demon]

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

[norguhtar]

Эм. Это за счет чего же?

[StMechanus]

На самом деле, все гораздо интересней :). Я замечаю сложность разработки лишь на первых порах. Обычно ко 2 итерации все становится как никогда просто, что весьма экономит время.

[yTko]

Цикла не вышло?) или планируется еще?

[StMechanus]

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

[ArtemDP]

Шеф, всё пропало? :) Прочитал статью — очень понравилось, то что искал «статья с которой можно начать»… Дочитал, искал линки на следующие статьи и не нашел… :( Но и за эту спасибо!