13 лучших практик для написания файлов конфигурации Spring

Java

Spring — это мощная среда приложений Java, которая предоставляет различные параметры конфигурации. Его основная функция заключается в обслуживании простых объектов Java (PO), называемых Beans. Spring использует внедрение зависимостей (DI) для упрощения и повышения тестируемости. Компоненты Spring и зависимости, а также службы, требуемые классом компонентов, указываются в файле конфигурации, который обычно имеет формат XML. Но это многословно и непрактично. Его сложно читать и управлять большими проектами, в которых необходимо определить множество компонентов Spring.

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

Навигация по статье

1. Добавьте описание к каждому файлу конфигурации

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

<beans>
    <description>
        This configuration file will have all beans
        which may be used for controlling transactions.
    </description>
    ...
</beans>

Одним из преимуществ использования тега описания является то, что вы можете легко использовать инструменты для извлечения описания из тега.

2. Используйте унифицированное соглашение об именах

То же самое относится и к Java-кодированию. Использование четких, описательных и согласованных разговорных имен в проектах очень полезно для понимания разработчиками конфигурации XML.

Например, для идентификатора компонента вы можете назвать его в соответствии с простым именем класса Java. НапримерOrderServiceDAOидентификатор компонента с именемorderServiceDAO. Для более крупных проектов вы можете добавить к идентификатору компонента префикс имени пакета.

3. Справочная схема не использует номер версии

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

Spring автоматически выберет самую высокую версию, доступную в зависимостях проекта (jars). Кроме того, по мере роста проекта версия Spring будет обновляться, и нам не нужно поддерживать все файлы конфигурации 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"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/context/
  http://www.springframework.org/schema/context/spring-context.xsd">

  <!-- Other bean definitions-->

</beans>

4. Внедрение сеттера имеет приоритет над внедрением конструктора

Spring предоставляет 3 типа внедрения зависимостей:внедрение конструктора, внедрение сеттера и внедрение метода. Обычно мы используем только первые два типа.

<!-- Constructor injection -->
<bean id="employeeDAO"   class="com.devcheats.dao.EmployeeDAO">
    <constructor-arg ref="datasource"/>
</bean>

<!-- Setter injection -->
<bean id="employeeDAO" class="com.devcheats.dao.EmployeeDAO">
    <property name="datasource"  ref="datasource">
</bean>

Внедрение конструктора может обеспечить простейшую потокобезопасность, т.е. объекты неизменяемы. Кроме того, это гарантирует, что объект не будет передан другим bean-компонентам без его полной инициализации.

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

Предпочитайте гибкость. Чтобы сделать объекты неизменяемыми или потокобезопасными, следуйте другим правилам программирования.

5. Для сопоставления параметров конструктора имена типов лучше, чем серийные номера.

Когда конструктор содержит более одного параметра одного типа или когда метка значения свойства уже занята, Spring позволяет вам использовать порядковый номер с нулевым счетом, чтобы устранить эти недоразумения. Например:

<!-- Index based constructor injection -->
<bean id="employeeDAO" class="com.devcheats.EmployeeDAO">
    <constructor-arg index="0" value="rest"/>
    <constructor-arg index="1" value="8080"/>
</bean>

Было бы лучше написать, используя свойства типа, как это:

<!-- Type based constructor injection -->
<bean id="employeeDAO" class="com.devcheats.EmployeeDAO">
    <constructor-arg type="java.lang.String" value="rest"/>
    <constructor-arg type="int" value="8080"/>
</bean>

Использование индекса может немного уменьшить многословие, но все же имеет тот недостаток, что он подвержен ошибкам и его труднее читать, чем использование свойств типа. Вы должны использовать индексирование только тогда, когда параметры конструктора неоднозначны.

6. Используйте краткий XML

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

<!-- Expanded version -->
<bean id="employeeDAO" class="com.devcheats.dao.EmployeeDAO">
    <property name="datasource">
        <ref bean="datasource"></ref>
        <value>datasource</value>
     </property>
</bean>

Приведенный выше код можно переписать в сжатой форме так:

<!-- Shorter/shortcut version -->
<bean id="employeeDAO" class="com.devcheats.dao.EmployeeDAO">
    <property name="datasource"  ref="datasource" value="datasource">
</bean>

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

7. По возможности повторно используйте определения bean-компонентов

Spring предоставляет механизм, подобный наследованию, для уменьшения дублирования информации о конфигурации и упрощения конфигурации XML. Определение подкласса может наследовать информацию о конфигурации от его суперкласса, который по существу действует как шаблон для подкласса. Это то, что называется повторным использованием в больших проектах. Все, что вам нужно сделать, это установить abstract=true в родительском компоненте, а затем указать его собственный родительский компонент в дочернем компоненте.

Возьмем в качестве примера определение источника данных:

<bean id="abstractDataSource" class="org.apache.commons.dbcp.BasicDataSource"
    destroy-method="close"
    p:driverClassName="${jdbc.driverClassName}"
    p:username="${jdbc.username}"
    p:password="${jdbc.password}" />

<bean id="concreteDataSourceOne"
    parent="abstractDataSource"
    p:url="${jdbc.databaseurlOne}"/>

<bean id="concreteDataSourceTwo"
    parent="abstractDataSource"
    p:url="${jdbc.databaseurlTwo}"/>

8. Всегда используйте id в качестве идентификатора бина

Вы можете указать идентификатор или имя в качестве идентификатора компонента. Хотя использование id не улучшит читаемость, оно позволяет синтаксическому анализатору XML лучше проверять достоверность ссылок на bean-компоненты. Если идентификатор нельзя использовать из-за ограничений XML IDREF, вы можете использовать имена в качестве идентификаторов компонентов. Ограничение XML IDREF заключается в том, что идентификатор должен начинаться с буквы (или знака препинания, как определено в спецификации XML), за которым следуют буквы, цифры, дефисы, символы подчеркивания, двоеточия и т. д. На практике редко возникают проблемы с ограничениями XML IDREF.

9. Избегайте автоматического подключения

Spring может автоматически связывать свои зависимости посредством самоанализа класса, поэтому вам не нужно явно указывать свойства и конструкторы компонента. Свойства компонента могут быть автоматически привязаны по имени свойства или сопоставлению типов. Конструкторы реализуют автоматическую привязку посредством сопоставления типов. Вы даже можете указать режим автоматического определения автоматического связывания, который поможет Spring выбрать подходящий механизм времени выполнения. Давайте посмотрим на следующий пример:

<bean id="employeeDAO"
    class="com.devcheats.dao.EmployeeDAO"
    autowire="byName"/>

EmployeeDAOИмена свойств класса используются в контейнере для соответствия экземплярам компонента. Автопривязка потенциально может избавить вас от набора текста и некоторой путаницы. Но в реальных проектах вам не следует использовать этот подход, потому что он приносит в жертву ясность конфигурации и удобство сопровождения. Многие руководства и введения активно рекламируют автопривязку как приятную функцию Spring, не упоминая о жертвах, которые влечет за собой эта функция.

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

10. Всегда используйте classpath в качестве префикса

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

Путь к классам определяется инструментом сборки и IDE. обычно включаютsrc/main/java,src/main/resources,src/test/java,src/test/resources.

<!-- Always use classpath: prefix-->
<import resource="classpath:/META-INF/spring/applicationContext-security.xml"/>

11. Ссылка на файл внешних свойств

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

Лучше сгруппировать их в отдельные файлы в зависимости от их использования или модуля, т.е. вся конфигурация, связанная с источником данных в JDBC, находится вjdbc.propertiesв файле.

<bean id="abstractDataSource" class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close"
        p:driverClassName="${jdbc.driverClassName}"
        p:username="${jdbc.username}"
        p:password="${jdbc.password}" />

и файл свойств

/* file://jdbc.properties */

jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.username=root
jdbc.password=password

12. Используйте проверку зависимостей во время разработки

Вы можете установить значение свойства проверки зависимостей в bean-компоненте вместо значения null по умолчанию, такого как простое, объектное или все, чтобы контейнер мог выполнять проверку зависимостей. Проверка зависимостей полезна, когда все свойства компонента (или класса свойств) должны быть явно установлены или связаны автоматически.

<bean id="abstractDataSource" class="org.apache.commons.dbcp.BasicDataSource"
    destroy-method="close"
    p:driverClassName="${jdbc.driverClassName}"
    p:username="${jdbc.username}"
    p:password="${jdbc.password}"
    dependency-check="all" />

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

13. Не злоупотребляйте внедрением зависимостей

И последнее замечание: Spring ApplicationContext может создавать для вас объекты Java, но не все объекты Java создаются путем внедрения зависимостей. Например, глобальные объекты не должны создаваться через ApplicationContext. Spring — отличная среда, однако с точки зрения удобочитаемости и управляемости проблемы с конфигурацией на основе XML могут стать заметными, когда определено большое количество bean-компонентов. Чрезмерное внедрение зависимостей может сделать XML-конфигурацию сложной и раздутой. запомнить! При использовании мощных IDE, таких как Eclipse и IntelliJ, Java-код более удобен для чтения, сопровождения и управления, чем XML-файлы.

Суммировать

XML — отличный способ настроить Spring. Но конфигурация на основе XML может стать утомительной и громоздкой при определении большого количества bean-компонентов. Spring предоставляет множество вариантов конфигурации. Надлежащее использование этих параметров может сделать конфигурацию XML более понятной, однако некоторые параметры, такие как автосвязывание (автоматическая привязка), имеют тенденцию снижать удобочитаемость и простоту обслуживания. Примеры, перечисленные в статье, помогут вам создать четкие и удобочитаемые файлы конфигурации XML.

Удачной учебы!

Первоисточник: https://howtodoinjava.com/best-practices/13-best-practices-for-writing-spring-configuration-files

Зависит откороль хорошийперевести

Категории