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

Я изучаю эту книгу (которую я очень рекомендую), и я смущен тем, как авторы объясняют, как можно настроить структуру Spring.

Вы можете увидеть примеры кода, которые используются в книге здесь. (Они доступны всем..) Код, который я имею в виду, будет кодом из главы 2, если вы хотите взглянуть.

В любом случае в книге указано, что существует 3 способа настройки контейнера Spring.


Конфигурация на основе XML

Для этого потребуется xml файл, похожий на что-то вроде этого:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" ...>

    <bean id="accountService" class="com.wiley.beginningspring.ch2.AccountServiceImpl">
        <property name="accountDao" ref="accountDao"/>
    </bean>

    <bean id="accountDao" class="com.wiley.beginningspring.ch2.AccountDaoInMemoryImpl">
    </bean>

</beans>

А затем, чтобы загрузить bootstrap Spring, код, который будет использоваться, будет:

ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/com/wiley/beginningspring/ch2/ch2-beans.xml");

В настоящий момент у меня нет путаницы.


Конфигурация на основе Java

В этом Способе конфигурации будет класс для конфигурации следующим образом:

@Configuration
public class Ch2BeanConfiguration {

    @Bean
    public AccountService accountService() {
        AccountServiceImpl bean = new AccountServiceImpl();
        bean.setAccountDao(accountDao());
        return bean;
    }

    @Bean
    public AccountDao accountDao() {
        AccountDaoInMemoryImpl bean = new AccountDaoInMemoryImpl();
        return bean;
    }
}

и код, который отвечает за загрузку Spring, выглядит так:

ApplicationContext applicationContext
            = new AnnotationConfigApplicationContext(Ch2BeanConfiguration.class);

Итак, все здесь ясно для меня. (Вид..) Я также хотел бы отметить, что здесь у нас есть аннотация, которая называется @Configuration...


Конфигурация на основе аннотаций

Последний доступный метод конфигурации, описанный в книге, - это Конфигурация на основе аннотаций.

Существует XML файл, как и в XML-конфигурации, однако гораздо меньше:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" ...>
    <context:component-scan base-package="com.wiley.beginningspring.ch2"/>
</beans>

Все beans имеют аннотации, такие как:

@Component, @Service

и т.д..

И все зависимости имеют аннотации:

@Autowired

чтобы beans мог быть введен.

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

ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/ch2-beans.xml");

Вот мои вопросы:

Почему (так называемая) настройка на основе аннотаций фактически использует ClassPaспасибоmlApplicationContext, но не AnnotationConfigApplicationContext выше? Последнее кажется гораздо более подходящим для использования в конфигурации, в которой есть слова "Аннотации, основанные", не так ли?

Конфигурация на основе Java, описанная в книге, похоже на то, что должно называться Конфигурация на основе аннотаций.

И метод, описанный в книге, описанный в книге, фактически мне кажется чем-то вроде: Конфигурация на основе XML с Autowired beans. У него даже нет аннотации @Configuration, которая имеет "Конфигурация на Java".

Сколько способов настроить фреймворк Spring?

Ответ 1

Чтобы избежать путаницы, мы должны понимать, что определение конфигурации и bean - это две разные вещи. Существует три способа определить конфигурацию, доступную в Spring 4 по умолчанию:

  • xml-based, когда вы описываете конфигурацию в XML файле;
  • конфигурация на основе java, когда конфигурация является классом Java, отмечена специальными аннотациями;
  • groovy, когда конфигурация является файлом с кодом Groovy;

И есть два способа добавить определение bean в приложение:

  • конфигурация внутри bean определение, когда вы добавляете beans вручную путем объявления в конфигурации.

    В этом случае определение будет основано на типе конфигурации. Для xml-config это будет тег <bean/>, для java-конфигурационного метода с аннотацией @Bean и beans {...} для Groovy.

  • определение на основе аннотации bean, когда вы отмечаете классы bean с конкретными аннотациями (например, @Component, @Service, @Controller и т.д.). Этот тип конфигурации использует сканирование классов.

    В этом случае вам нужно указать директиву для сканирования пути к классам. Для xml-config это будет <context:component-scan base-package="..."/>, для аннотации java-config - @ComponentScan для вызова Groovy ctx.'component-scan'(...).

Как вы видите, вы можете использовать конфигурации и определения bean в разных комбинациях.

Обратите внимание, что если вы используете конфигурацию на основе xml, вы можете выбрать подход к инъекции зависимостей: вручную в xml или с помощью аннотаций (@Autowire, @Required и т.д.). В последнем случае вы должны определить <context:annotation-config/>. Но не путайте определение bean и управления впрыском зависимостей.

Теперь на основе этой точки зрения попытайтесь ответить на ваши вопросы:

Почему (так называемая) настройка на основе аннотаций фактически используется ClassPaспасибоmlApplicationContext, но не AnnotationConfigApplicationContext выше?

Автор книги смешивает понятия. Фактически, это конфигурация на основе xml с определением bean на основе аннотаций.

Конфигурация на Java, описанная в книге, выглядит как следует называть конфигурацией на основе аннотаций.?

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

Сколько способов настроить Spring framework?

Итак, по умолчанию у нас есть три способа описать конфигурацию и два способа определить beans. Это превращает шесть способов настройки рамки Spring (по умолчанию). Но, конечно, все эти способы можно использовать в сочетании друг с другом.

Ответ 2

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

  • Конфигурация на основе XML - это было с начала - версия 1 - см. javadoc для ClassPaспасибоmlApplicationContext. Это было в марте 2004 года, время J2EE 1.4, у которого была огромная конфигурация xml и Spring, было большим упрощением (кроме XML, но проще). Это использует XML для всего, включая указание autowiring или какие зависимости идут прямо (ваш пример ref = "accoundDao" ).

  • Конфигурация на основе аннотаций - в Spring 2.5 - это стало реакцией на Java EE 5, новые анотации, такие как @Autowired, в XML файлах все еще была какая-то конфигурация контекста - обычно вы определяли, какие пакеты должны были сканироваться, а остальная часть была сделана автоматически на основе аннотаций - отсюда и название.

  • Конфигурация на основе Java появилась с Spring 3, была улучшена в более поздних версиях. Это когда AnnotationConfigApplicationContext и была введена аннотация для настройки - вы можете полностью удалить XML → java config. Хотя это стало практичным только позже с версией 4+, из-за большого количества хелперных тегов xml для aop, jdbc и т.д.

Помимо этих 3 (2 фактически как 1 и 2 используют один и тот же класс ApplicationContext), это другие способы создания контекста:

  • Посмотрите на все реализующие классы ApplicationContext interface
  • SpringJUnit4ClassRunner для тестов junit
  • Я уверен, что есть другие способы, о которых я не знаю

Ответ 3

Не совсем. Есть только два способа настройки фрейма Spring. Двумя основными инструментами настройки для структуры Spring являются:

  • Файлы XML (внешние файлы java)
  • Java (5 +) аннотации (внутри java файлов)

Оба они могут использоваться для:

  • настроить контекст приложения (что означает добавление beans) - конструкторы конкретных контекстов приложения принимают файлы xml, пакеты для сканирования или непосредственно названные классы для загрузки
  • загружать контекст приложения в случае веб-приложения - с помощью web.xml vs с использованием класса, реализующего WebApplicationInitializer

И последнее, но не менее важное:

  • вы можете сканировать аннотации из файла конфигурации xml с помощью <context:component-scan/>
  • вы можете загрузить xml файл из аннотированной конфигурации bean с помощью @import

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

Третий способ, называемый настройкой на основе аннотаций, - это просто смешивание двух режимов, в которых вы используете конфигурацию xml на более высоком уровне и просто сканируете пакеты для дополнительных beans.


TL/DR: существует только два способа настройки контекста приложения в структуре Spring:

  • конфигурационные файлы xml
  • аннотации java

и их можно смешать

но каждый bean может быть объявлен тремя способами:

  • из XML файла
  • с аннотацией @Bean внутри @Configuration аннотированной bean
  • непосредственно с @Component (или любой из специализированных аннотаций @Controller, @Service и т.д.)

Теперь для ваших точных вопросов:

Почему (так называемая) настройка на основе аннотаций используется с использованием ClassPaспасибоmlApplicationContext, но не AnnotationConfigApplicationContext выше?

Так как ApplicationContext сначала инициализируется, формирует файл конфигурации xml. Сканирование пакетов происходит позже с помощью тегов <context:scan ...>. Вы используете AnnotationConfigApplicationContext, если вы непосредственно инициализируете его из классов конфигурации или сканирования пакетов.

Конфигурация на Java, описанная в книге, выглядит так, как следует называть "Аннотационная конфигурация".

Они называют это Java, потому что ему не нужен xml, поэтому в конфигурации используется только Java

Ответ 4

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

Определение конфигурации

Spring 4 содержит 3 способа определения его конфигурации. Они

введите описание изображения здесь

Преимущества аннотации:

  • Все information is in a single file (нет необходимости открывать два файла для настройки заданного поведения)

  • Когда класс изменяется, no need to modify the xml file

  • Аннотации часто говорят, что они более интуитивно понятны и надежны при повторном кодировании кода приложения. Кроме того, они извлекают выгоду из лучшего руководства IDE, например, для маскировки. Но они смешивают код приложения с проблемами DI. Приложение зависит от структуры. Четкое разделение практически невозможно. Annotations are also limited when describing different injection behaviour at the same place (constructor, field) dependent on other circumstances (e.g. robot legs problem). Кроме того, они не позволяют рассматривать внешние классы (код библиотеки), как ваш собственный источник. Поэтому считается, что они работают быстрее, чем XML.

Преимущества файла xml:

  • Четкое разделение между POJO и его поведением

  • Если вы не знаете, какой POJO несет ответственность за поведение, легче найти POJO (поиск в подмножестве файлов, а не во всем исходном коде)

  • XML имеет единственное положительное значение декларативного стиля, который определен четко отделен от самого кода приложения. Это не зависит от проблем с ИС. Нижними являются verbosity, poor re-factoring robustness и a general runtime failure поведение. Существует только общая (XML) поддержка инструмента с небольшим преимуществом по сравнению с поддержкой IDE, например. Ява. Кроме того, этот XML поставляется с служебными данными производительности, поэтому обычно slower than code solutions.

XML и ссылка на основе аннотации:

Groovy Ссылка на ссылку:

Bean Определение:

Есть 2 способа bean Определение: введите описание изображения здесь

Сканирование classpath:

Для xml-config для Groovy ctx.'component-scan'(...) -команды будет <context:component-scan base-package="..."/>, для аннотации java-config - @ComponentScan.

Инъекция зависимостей:

В конфигурации на основе xml dependency injection можно выполнить вручную в xml или с помощью annotations (@Autowire, @Required и т.д.). В этом случае необходимо определить <context:annotation-config/>

Вопрос и ответ:

Q1: Почему (так называемая) настройка на основе аннотаций используется с использованием ClassPaспасибоmlApplicationContext, но не AnnotationConfigApplicationContext выше?

Ans:. Это xml-конфигурация с определением bean на основе аннотаций.

Контекст приложения:

AnnotationConfigApplicationContext:

1. AnnotationConfigApplicationContext и родительский контекст

ClassPaспасибоmlApplicationContext:

Q2: конфигурация на Java, описанная в книге, похоже на то, что следует назвать конфигурацией на основе аннотаций.

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

Но тщательно мы должны понимать , как эта иерархия исходит от xml к основанной на аннотации и, наконец, Groovy?

Альтернатива настройкам XML предоставляется с помощью аннотационной конфигурации, которая основывается на метаданных байт-кода для подключения компонентов вместо объявлений с угловыми скобками. Вместо использования XML для описания проводки bean разработчик перемещает конфигурацию в сам класс компонента, используя аннотации к соответствующему объявлению класса, метода или поля. Как уже упоминалось в разделе "Пример: RequiredAnnotationBeanPostProcessor" , использование BeanPostProcessor в сочетании с аннотациями является распространенным средством расширения Spring IoC. Например, Spring 2.0 представил возможность принудительного применения необходимых свойств с помощью аннотации @Required.

Spring 2,5 позволил следовать тому же общему подходу к вводу инъекции Spring s. По существу, аннотация @Autowired предоставляет те же возможности, что описаны в разделе Раздел 6.4.5, "Сотрудники Autowiring" , но с более мелкозернистым управлением и более широкое применение.

Spring 2.5 также добавлена ​​поддержка аннотаций JSR-250, таких как @PostConstruct и @PreDestroy.

Spring 3.0 добавлена ​​поддержка аннотаций JSR-330 (зависимость для Java), содержащихся в пакете javax.inject, таких как @Inject и @Named. Подробности об этих аннотациях можно найти в разделе .

Q3: Сколько способов настроить Spring framework?

Ans:

Theoretically, 3 способа описания конфигурации и 2 способа определения beans. Похоже, 3 * 2 = 6 способов настройки рамки Spring (по умолчанию). Все эти способы могут использоваться в сочетании друг с другом.

But Actually, в одном слове мы можем настроить структуру Spring с помощью xml или annotations.

Ответ 5

Я не взглянул на книгу, но ваши предположения на самом деле верны.

Чтобы запустить приложение Spring и создать все beans, созданное каркасом с использованием настроенного XML beans, вы должны использовать ClassPaспасибоmlApplicationContext.

Есть два способа настройки beans в Spring:

1) XML beans 2) Аннотационный подход

В основном XML beans использовался в Spring 2.5-3, а подход "Аннотации" используется больше в Spring 4.

@Bean // is a way to create a bean. It is the equalivant of the beans tag in XML.

@Configuration // is a way to tell the Spring container that this class is a list of configuration beans

Spring имеет 2 Spring контейнера:

1) BeanFactory 2) ApplicationContext

A BeanFactory - самый простой контейнер и принимает только один файл конфигурации. ApplicationContext - это самый продвинутый контейнер Spring и используется в корпоративных приложениях, поскольку он принимает массив конфигурационных файлов, имеет интеграцию JNDI, интеграцию EJB и поддерживает интернационализацию сообщений.

Я надеюсь, что это поможет.

Ответ 6

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

  • XML: вам нужно зарегистрировать свой spring bean внутри контекстного файла xml с помощью <bean/>
  • Конфигурация Java: вы должны использовать @Configuration и @Bean для регистрации spring bean в контексте.

  • Аннотация: при использовании @Component и его друзей на самом деле можно использовать другие 2, используя:

    • в xml с помощью <context:component-scan/>
    • в конфигурации java с помощью @ComponentScan

Зачем использовать ClassPathXmlApplicationContext, потому что он использовал xml для настройки сканирования компонентов, но если он использовал @ComponentScan, то обязательно используйте AnnotationConfigApplicationContext

Итак, для меня я рассматриваю это как два способа инициализировать конфигурацию контекста xml или java spring, а параметр Annotation может использоваться любым из них или вообще не использоваться.

Ответ 7

Три способа настройки структуры spring вовсе не должны быть взаимоисключающими. Фактически, я предполагаю, что в среднем вы найдете по крайней мере две из них, которые используются вместе.

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

AnnotationConfigApplicationContext может использоваться для запуска чистого контекста на основе аннотаций, но вам нужно будет передать все ваши классы, аннотированные как @Component или производные, вместо того, чтобы передавать одиночный (или пара) @Configuration -номинированный класс - который обычно непрактичен.

Хотя это почти то же самое, что и статическое перечисление beans в конфигурации XML или Java, тот факт, что вам нужно будет сделать это в коде при создании самого контекста приложения, делает его менее полезным, поскольку вы можете это полезно для различных умных способов автоматического запуска контекста приложения (в веб-контекстах и ​​т.д.).

Вот почему вы, вероятно, захотите иметь полные метаданные всего объекта, собранные за один раз, и это может быть достигнуто только с помощью конфигурации на основе XML или Java, которая основывается на "централизованных" метаданных, описывающих весь объект граф.

Для обоих подходов на основе XML и Java эти "централизованные метаданные" (<beans> или @Configuration) могут быть определены статически (с явными определениями <bean> или @Bean) или динамически (используя <component-scan> или @ComponentScan). Поэтому разумно сказать, что эти два подхода - это просто разные форматы с почти такими же возможностями, которые могут принести пользу конфигурации на основе аннотаций для сбора "децентрализованных" метаданных.