Споры на данную тему в стане приверженцев Spring Framework существуют с момента релиза третьей версии данного фреймворка. И хотя в версии 2.5 уже можно было частично заменить конфигурирование приложения аннотациями, полностью отказаться от XML было нереально.
Оба подхода имеют свои плюсы и минусы, и на мой взгляд, если нет возможости выбрать какой-то конкретный, то логично использовать их вместе.
Стоит отметить забавный момент, что среди разработчиков фреймворка во время Spring Framework 3 не было единого мнения по этому поводу - в книге Pro Spring 3 использовались XML-конфигурации, а в книге Pro Spring MVC: with Web Flow - аннотации.
Оба подхода имеют свои плюсы и минусы, и на мой взгляд, если нет возможости выбрать какой-то конкретный, то логично использовать их вместе.
Стоит отметить забавный момент, что среди разработчиков фреймворка во время Spring Framework 3 не было единого мнения по этому поводу - в книге Pro Spring 3 использовались XML-конфигурации, а в книге Pro Spring MVC: with Web Flow - аннотации.
XML
С XML-конфигурациями в Spring Framework я работаю ещё с версии 2.5. На тот момент альтернатив не было. Зато можно было хотя бы использовать аннотацию @Autowired для внедрения зависимостей, чему я предпочитал непосредственное указание зависимостей в XML через сеттеры и конструкторы. С тех пор я унаследовал привычку конфигурировать практически всё при помощи XML, в том числе JPA и Hibernate. Для меня главным аргументом в пользу XML была возможность изменять настройки приложения на лету без необходимости собирать проект заново. Такая необходимость возникала, но нечасто. Хотя объективности ради стоит заметить, что именяющиеся компоненты Spring-приложения вполне можно конфигурировать properties-файлами или через JNDI.
Против XML главным аргументом всегда являлся тот факт, что в больших проектах XML-конфигурацию очень сложно читать ввиду большого количества конфигурируемых компонентов и нередко большого количества файлов конфигурации. В качестве примера можно привести проекты CMDBuild и OpenOLAT.
Актуальность XML-конфигураций теряется ещё и в том случае, когда разработчик не имеет физического доступа к развёрнутому приложению, как это зачастую бывает в серьёзных организациях. Именно это и стало для меня решающим фактором в пользу перехода на использование аннотаций.
Аннотации
В пользу аннотаций можно однозначно записать простоту. Конфигурирование приложения посредством аннотаций происходит проще, чем при использовании XML. Всё делается тем же Java-кодом. Разработчику в данном случае даже не обязательно знать XML, хотя я сильно сомневаюсь, что в природе существуют Java-разработчики без базовых знаний XML.
Отдельно стоит отметить тот факт, что в мире Java EE всё давно конфигурируется при помощи аннтоаций: EJB, CDI, JPA и т.д. и Spring Framework совместим со всеми аннотациями Java EE.
Ну а минус, соответственно, заключается в отсутствии возможности конфигурировать проект на лету.
Groovy
Отдельно стоит упомянуть возможность конфигурировать Spring-приложения при помощи Groovy-классов. Если классы конфигурации не компилировать, а оставлять скриптами, то приложение можно будет конфигурировать на лету. И при этом сам процесс конфигурирования будет значительно более гибким, чем даже при использовании XML. Но это если в проекте используется Groovy.
Вывод
Вывод прост - нужно стремиться к использованию аннотаций, раз это действительно проще, правильнее и рекомендуется разработчиками Spring Framework. Тем более, что в Java EE это стандарт, а на горизонте маячит Spring Boot, хотя никто не запрещает и там использовать XML.
Однако
в плане маппингов JPA и Hibernate я так и остался при мнении, что
использование XML значительно удобнее аннотаций, особенно в случаях,
когда POJO-классы находятся в отдельной от бизнес-логики библиотеке. В
этом случае клиентским Java-приложениям при использовании тех же API не
нужно будет тянуть ненужные зависимости.
Ещё к аннотациям и конфигурации в java-коде: IDE и компилятор проверят тебе имена и типы бинов, которые ты подсовываешь друг другу, и если ты опечатался в имени бина, или подсунул бин неподходящего типа, то узнаешь об этом в следующую секунду, а не после разворачивания и запуска приложения.
ОтветитьУдалить