Весна - путаница по поводу конфигурации?

Где-то я читал Spring предлагает удобство по настройке. Но пользователи Spring вносят так много изменений в конфигурацию, что теперь я действительно запутался в использовании конфигурации xml или аннотации.

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

Примеры в SO показывают, что многие новички, такие как я, запутываются в конфигурации.

• ссылка-1

  Я, кажется, не понимаю функциональности позади <context:annotation-config>и <context:component-scan>.

  Из того, что я прочитал, они, кажется, обрабатывают разные аннотации (@Required, @Autowired и т. Д. Против @Component, @Repository, @Service и т. Д.), Но также и из того, что я читал, они регистрируют одни и те же классы постпроцессора бина.

  Чтобы запутать меня еще больше, есть annotation-configатрибут на <context:component-scan>...

• ссылка 2

  У меня все еще есть тег сканирования компонента:

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

  но у меня есть еще один тег (который похож на похожую задачу), этот:

  <annotation-driven />

  В чем разница между этими двумя тегами? Другая «странная» вещь заключается в том, что предыдущий пример (в котором не используется тег, управляемый аннотациями) очень похож на проект, созданный STS с использованием проекта Spring MVC Template, но если я удалю тег, управляемый аннотациями, из его конфигурации файл проекта не запускается и выдает следующую ошибку: HTTP Status 404 - ...

Spring 3.2 больше не нуждается в cglib для прокси, но в более низких версиях используется cglib. Цитата из блога источника

Для генерации таких прокси Spring использует стороннюю библиотеку cglib. К сожалению, этот проект больше не активен. В Spring 3.2 очень вероятно, что Spring по умолчанию будет использовать Javassist.

Достаточно ли этого, чтобы предположить, что Spring - это путаница в конфигурации?

Spring стремится предоставить вам среду, в которой существует «соглашение о конфигурации». Однако реальность такова, что приложениям Spring необходимо определенное количество настроек.

В Spring 2.5.x и более ранних версиях общепринятым подходом было предоставление этой конфигурации через XML. В Spring 3.0+ идиоматическим способом является использование аннотаций (что также поощряется Java EE6 / 7).

В качестве примечания, может быть забавно (печально?) Видеть аннотированную сущность JPA, довольно просто добавить 4+ аннотации к одному полю ....

<annotation-driven />

Вы должны указать схему XML, откуда это происходит.

Скорее всего, это в контексте стратегии обработки транзакций JPA при определении менеджера транзакций (см. 9.5.6. Использование @Transactional в документации Spring)

Когда вы определяете обработку транзакций на основе аннотаций - Spring AOP автоматически создает аспекты для вашего метода, чтобы запустить (или проверить на наличие) транзакцию до вызова метода, а затем зафиксировать (или выполнить откат в случае исключения) после завершения метода ivokation.

Я обнаружил, что создание IoC / Bean на основе аннотаций удобно, когда у вас есть одноэлементная реализация, но, возможно, потребуется заменить ее.

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

В этих случаях я объявляю bean-компонент в config и обычно делаю инъекцию в конструктор любой зависимости, которая мне нужна. Затем в классе, который будет использовать указанный bean (s) I, @Autowireа затем @Qualifier("")- так должны работать фабрики.

Синглтон - это фабричный метод, который возвращает только 1 результат. Когда это неприменимо, тогда нужно смешать это.

Что касается использования компонентного сканирования или нет, то это действительно зависит от вышеуказанных критериев и здравого смысла. Я, как правило, очень подробно рассказываю о сканировании компонентов пакета. Таким образом, я могу создать другой контекст приложения для тестирования, где я могу смоделировать внешние зависимости (например, db), в то же время тестируя остальную часть моей настройки IoC.

Кроме того, @Componentв моем проекте нет библиотечного кода. Вы никогда не знаете, когда и как вам понадобится использовать боб, и если вы @Componentэто сделаете, вы можете случайно обнаружить его при сканировании и ограничить его повторное использование. Для этих случаев у меня обычно есть контекст приложения, определенный в библиотеке с некоторыми удобными объявлениями bean-компонентов по умолчанию, которые мой основной проект МОЖЕТ включить с импортом в его контекст приложения.

Здесь нет религии. Просто опыт, чтобы передать

Spring предлагает варианты, изначально была только проводка на основе xml. Позже была добавлена ​​проводка на основе аннотаций.
Теперь можно (и многие люди так делают) использовать сочетание обоих.
Существует достаточно документации, включенной в Spring и / или загружаемой с веб-сайта springsource. Есть профессиональное обучение (никогда не делал, не могу ручаться за это), и довольно много хороших книг (мне нравится APress Pro Spring, выберите правильный выпуск для версии Spring, которую вы используете).