Самое лучшее в Spring — это несколько способов решить проблему. Самое плохое в Spring — то, что есть несколько способов решить проблему!
Одной из самых больших проблем при использовании Spring является выбор наилучшего способа реализации решений. Как и большинство из нас, разработчиков, мы попадаем в Google или собираем книги о Spring. Это может заставить нас двигаться в правильном направлении. Много раз мы находим противоречивые конфигурации между подходами реализации. Для новичков Spring это может быть непросто и может привести к серьезной путанице в будущем.
Spring Namespaces
У нас нет номеров версий в ссылках схемы.
Вместо:
<?xml ?> <beans > ... </beans>
Используйте эту конфигурацию:
<?xml ?> <beans > ... </beans>
ЗАЧЕМ?
Spring автоматически выбирает самую высокую версию, доступную из зависимостей проекта (jars). По мере развития проекта версия Spring будет обновляться, и нам не нужно будет поддерживать все файлы конфигурации XML, чтобы увидеть новые функции.
Один XML-файл начальной загрузки
Множество примеров использования нескольких файлов конфигурации XML. Приложение обычно имеет несколько файлов конфигурации XML, но должен быть только ОДИН файл начальной загрузки. Этот файл начальной загрузки должен использовать <import /> для включения других файлов конфигурации.
Префикс Classpath
Всегда используйте префикс: путь к классам
При импорте ресурсов, XML конфигурации, свойства и т.д., всегда используйте
путь к классам:
или на
пути к классам *: префикс.
Это обеспечивает последовательность и ясность в расположении ресурса. Не все функции Spring ведут себя одинаково, а
classpath: гарантирует согласованность.
Путь к классу определяется инструментом сборки и IDE. Обычно это
src / main / java для java-кода,
src / main / resources для не-java-зависимостей и для тестов:
src / test / java для java-кода и
src / test / resources для не-java-ресурсов.
Пример:
<import />
Бин Нейминг
Spring Context — это контейнер для бинов приложения. Каждый боб уникально идентифицируется по своему имени. Атрибут XML «id» чаще всего используется для определения имени компонента. Атрибут «id» великолепен, поскольку по закону XML он уникален для каждого файла.
<bean id="accountService" class="com.gordondickens.services.AccountService/>
Однако, если мы хотим использовать специальные символы в имени или предоставить псевдонимы имени, мы можем использовать предоставленный Spring атрибут «name».
<bean class="com.gordondickens.services.AccountService/>
В Spring 3.1 добавлена функция профиля , обеспечивающая возможность настройки bean-компонентов по категориям или регионам.
В версии 3.1 Spring перегружает атрибут «id» XML, позволяя нескольким bean-компонентам с одинаковым «id» в файле XML по профилю.
<?xml ?> <beans > <beans > <bean id="dataSource" class="..."/> <bean id="messagingProvider" class="..."/> </beans> <beans > <bean id="dataSource" class="..."/> <bean id="messagingProvider" class="..."/> </beans> </beans>
Подробнее о профилях Spring 3.1 см. В моем блоге. Профили среды Spring 3.1.
Внедрение зависимости
Внедрение зависимостей является одним из основных принципов Spring Framework. DI предоставляет разработчикам возможность «связывать вместе» взаимосвязи компонентов в конфигурации вместо кодирования взаимосвязей.
Существует два способа выполнения DI: Constructor Injection или Setter Injection.
Enterprise Spring Best Practices. Часть 2. Архитектура приложений описывает многоуровневый подход к приложениям. В этом многоуровневом подходе мы можем ожидать, что бины будут внедряться вместе между слоями.
Например, проводка снизу вверх:
- DataSource , общий класс JDBC для подключения к базе данных, внедряется в наши компоненты персистентности
- Персистентные бины вводятся в наши сервисные бины
- Служебные бины вводятся в наши контроллеры
Конструктор Инъекция
Внедрение в конструктор выполняется с использованием <bean /> node <constructor-arg .
Безопасность потоков — это веский аргумент в пользу использования конструкторов. Сделать бобы неизменными — это самая дешевая безопасность потоков, которую мы можем кодировать.
В следующем примере мы видим конфигурацию базы данных HSQLDB в памяти с идентификатором «dataSource». Фасоли AccountRepositoryImpl вводится с данной реализацией , когда начинается весенний.
<bean id="accountRepository" class="com.gordondickens.repository.internal.AccountRepositoryImpl"> <constructor-arg /> </bean> <!-- Spring's In-Memory DB Config, using HSQLDB --> <!-- Note the HSQLDB driver must be in the project dependencies --> <jdbc:embedded-database id="dataSource" > <jdbc:script /> <jdbc:script /> </jdbc:embedded-database>
Сеттер Инъекция
Инъекция сеттера предоставляет возможность инъекции бинов через метод сеттера. Традиционно, это был предпочтительный выбор для многих разработчиков, потому что конфигурация легче читать.
<bean id="accountRepository" class="com.gordondickens.repository.internal.AccountRepositoryImpl"> <property /> </bean>
Сторонние бобы
Любой класс Java может быть использован в среде Spring. Возможны компоненты инфраструктуры, такие как ConnectionFactory ActiveMQ
или OracleDataSource Oracle
.
С сторонними компонентами, у которых нет источника или мы не хотим вмешиваться в источник, выбор для DI сделан для нас.
Внешние свойства
Конфигурация развертывания требует настройки параметров среды, таких как свойства подключения к базе данных.
Поскольку XML может быть хрупким, лучше всего перенести настройки в файлы свойств. Это позволяет группе развертывания изменять конфигурацию ресурса с меньшим риском.
Spring предоставляет PropertyPlaceholderConfigurer для этой цели.
Конфигурация замены свойства
<context:property-placeholder /> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" > <property /> <property /> <property /> <property /> </bean>
Файл свойств
\:hsqldb\:mem\:mydb database.password=
Фасоль
Ознакомьтесь с
рекомендациями Enterprise Spring — часть 1 — Конфигурация проекта для конфигурации ведения журнала.
Java Util Logging
Включить обработку классов java.util.logging с SLF4J. Зарегистрируйте следующее в вашей конфигурации Spring:
<!-- Enable handling of java.util.logging through SLF4J --> <bean id="slf4JBridgeHandler" class="org.slf4j.bridge.SLF4JBridgeHandler" /> <bean class="org.slf4j.bridge.SLF4JBridgeHandler" />
System.out и System.err
Чтобы включить обработку сообщений System.out и System.err , зарегистрируйте в своей конфигурации Spring следующее:
ПРИМЕЧАНИЕ. Это НЕ рекомендуется для продолжающейся разработки, но для миграции плохого кода для использования ведения журнала.
<!-- System.out.println & System.err.println handling through SLF4J --> <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property /> <property /> <property > <list> <!-- Set log level for System.out --> <util:constant /> <!-- Set log level for System.err --> <util:constant /> </list> </property> </bean>
Зависимость Maven для SysOutOverSLF4J
<dependency> <groupId>uk.org.lidalia</groupId> <artifactId>sysout-over-slf4j</artifactId> <version>1.0.2</version> </dependency>
Лучшие практики
- НЕ используйте номера версий с пространствами имен схемы Spring
- Всегда используйте префикс classpath: / для ссылок на ресурсы с содержанием
- Всегда используйте один XML-файл конфигурации для начальной загрузки приложения или тестов
- Используйте атрибут «id» XML для идентификации бина
- Используйте конструктор для повышения безопасности потока
- Используйте Свойства для настраиваемых ресурсов
- НЕ используйте SysOutOverSLF4J ни для чего, кроме миграции