Конфигурация XML по сравнению с конфигурацией на основе аннотаций [закрыто]

В нескольких крупных проектах, над которыми я работал в последнее время, становится все более важным выбирать то или иное (XML или аннотации). По мере роста проектов согласованность очень важна для удобства обслуживания.

У меня следующие вопросы: каковы преимущества конфигурации на основе XML по сравнению с конфигурацией на основе аннотаций и каковы преимущества конфигурации на основе аннотаций над конфигурацией на основе XML?

Аннотации имеют свое применение, но они не являются единственной серебряной пулей, способной убить конфигурацию XML. Я рекомендую смешать два!

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

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

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

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

Здесь есть более широкая проблема: внешние и встроенные метаданные. Если ваша объектная модель будет сохраняться только одним способом, то встроенные метаданные (т. Е. Аннотации) будут более компактными и читаемыми.

Если, однако, ваша объектная модель была повторно использована в разных приложениях таким образом, что каждое приложение хотело сохранить модель по-разному, тогда более подходящим становится экстернализация метаданных (то есть дескрипторов XML).

Ни один из них не лучше, поэтому поддерживаются оба, хотя аннотации более модны. В результате в новых фреймворках типа «волосы в огне», таких как JPA, им уделяется больше внимания. Более зрелые API, такие как собственный Hibernate, предлагают и то, и другое, потому что известно, что ни одного из них недостаточно.

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

С другой стороны, конфигурация Spring XML для меня - это просто конфигурация

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

Использование @Autowire, @Elementдля указания фреймворка, что делать с классом, - хорошее использование аннотаций.

Помещать URL в @Webserviceаннотацию - плохой стиль.

Но это только мое мнение. Граница между взаимодействием и настройкой не всегда ясна.

Я использую Spring уже несколько лет, и объем XML, который требовался, определенно становился утомительным. Между новыми схемами XML и поддержкой аннотаций в Spring 2.5 я обычно делаю следующее:

1. Использование "сканирования компонентов" для автозагрузки классов, использующих @Repository, @Service или @Component. Обычно я даю каждому bean-компоненту имя, а затем соединяю их вместе с помощью @Resource. Я считаю, что эта сантехника не очень часто меняется, поэтому аннотации имеют смысл.

2. Использование пространства имен «aop» для всех АОП. Это действительно отлично работает. Я все еще использую его для транзакций, потому что размещение @Transactional повсюду - это своего рода перетаскивание. Вы можете создавать именованные pointcut для методов в любой службе или репозитории и очень быстро применять рекомендации.

3. Я использую LocalContainerEntityManagerFactoryBean вместе с HibernateJpaVendorAdapter для настройки Hibernate. Это позволяет Hibernate легко автоматически обнаруживать классы @Entity в пути к классам. Затем я создаю именованный bean-компонент SessionFactory, используя «factory-bean» и «factory-method» со ссылкой на LCEMFB.

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

«Имена компонентов» в Spring образуют дополнительный уровень абстракции по сравнению с реализующими классами. В XML bean-компоненты определяются и ссылаются на их имя bean-компонента. С аннотациями на них ссылаются их класс / интерфейс. (Хотя имя bean-компонента существует, вам не нужно его знать)

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

Я считаю, что наглядность - это большая победа с подходом, основанным на XML. Я считаю, что XML на самом деле не так уж плох, учитывая различные инструменты для навигации по XML-документам (например, окно Visual Studio + ReSharper File Structure).

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

Я не знаю; в конце концов, XML Hell мне не кажется таким уж плохим.

Это зависит от того, что вы хотите настроить, потому что есть некоторые параметры, которые нельзя настроить с помощью аннотаций. Если посмотреть со стороны аннотаций:

• плюс: аннотации менее разговорчивы
• минус: аннотации менее заметны

Вам решать, что важнее ...

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

(за некоторыми исключениями: например, если вы выбираете конфигурации на основе XML, можно использовать аннотацию @Autowire. Это смешивание, но это помогает как удобочитаемость, так и удобство обслуживания)

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

Я предпочитаю конфигурацию на основе Java без (или с минимальными) аннотациями. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Возможно, я ошибаюсь, но я думал, что аннотации (как в Java @Tag и C # [Attribute]) - это параметр времени компиляции, а XML - параметр времени выполнения. Для меня это говорит о том, что они не эквивалентны и имеют разные плюсы и минусы.

Я также считаю, что сочетание - это лучший вариант, но это также зависит от типа параметров конфигурации. Я работаю над проектом Seam, который также использует Spring, и я обычно развертываю его на разных серверах разработки и тестирования. Итак, я разделился:

• Конфигурация для конкретного сервера (например, абсолютные пути к ресурсам на сервере): Spring XML-файл
• Внедрение bean-компонентов в качестве членов других bean-компонентов (или повторное использование значения, определенного Spring XML во многих bean-компонентах): Аннотации

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

Что касается контейнера DI, я считаю, что DI на основе аннотаций злоупотребляет использованием аннотаций Java. Сказав это, я не рекомендую широко использовать его в вашем проекте. Если вашему проекту действительно нужна мощность контейнера DI, я бы рекомендовал использовать Spring IoC с опцией конфигурации на основе Xml.

Если это просто ради модульного теста, разработчики должны применять шаблон Dependency Inject в своем коде и пользоваться преимуществами имитирующих инструментов, таких как EasyMock или JMock, для обхода зависимостей.

Вам следует избегать использования контейнера DI в неправильном контексте.

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

Пожалуйста, обратитесь по следующим ссылкам. Они тоже могут быть полезны.

1. Аннотации против XML, преимущества и недостатки
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Это классический вопрос типа «Конфигурация против соглашения». В большинстве случаев ответ подсказывает личный вкус. Однако лично я предпочитаю конфигурацию (т.е. основанную на XML), а не конвенцию. IDE IMO достаточно надежны, чтобы преодолеть часть ада XML, которую люди часто связывают с построением и поддержкой подхода на основе XML. В конце концов, я считаю, что преимущества конфигурации (например, служебные программы для создания, обслуживания и развертывания файла конфигурации XML) в конечном итоге перевешивают Конвенцию.

Я использую оба. В основном XML, но когда у меня есть набор компонентов, которые наследуются от общего класса и имеют общие свойства, я использую аннотации для них в суперклассе, поэтому мне не нужно устанавливать одни и те же свойства для каждого компонента. Поскольку я немного помешан на управлении, я использую @Resource (name = "referBean") вместо простого автоматического подключения (и избавляю себя от множества проблем, если мне когда-либо понадобится еще один bean того же класса, что и исходный referBean) ,

По моему опыту, есть некоторые плюсы и минусы конфигурации аннотаций:

• Когда дело доходит до конфигурации JPA, поскольку она выполняется один раз и обычно не меняется довольно часто, я предпочитаю придерживаться конфигурации аннотаций. Возможно, есть опасения относительно возможности увидеть более полную картину конфигурации - в этом случае я использую диаграммы MSQLWorkbench.
• Конфигурация XML очень хороша для получения более полной картины приложения, но может быть обременительной, чтобы найти некоторые ошибки до времени выполнения. В этом случае аннотация Spring @Configuration звучит как лучший выбор, поскольку она позволяет вам видеть более широкую картину, а также позволяет проверять конфигурацию во время компиляции.
• Что касается конфигурации Spring, я предпочитаю комбинировать оба подхода: используйте @Configuration аннотацию с интерфейсами Services и Query и конфигурацию xml для dataSource и конфигурацию Spring, такую ​​как context: component-scan base-package = "..."
• Но конфигурация xml битов с аннотациями java, когда дело доходит до конфигурации потока (Spring Web Flow или Lexaden Web Flow), поскольку чрезвычайно важно видеть более полную картину всего бизнес-процесса. И это звучит громоздко, чтобы реализовать его с использованием аннотаций.

Я предпочитаю комбинировать оба подхода - аннотации Java и необходимый минимум xml, который минимизирует ад конфигурации.

Для Spring Framework мне нравится идея использовать аннотацию @Component и установить параметр "component-scan", чтобы Spring мог найти мои Java-бины, так что мне не нужно определять все мои бины ни в XML, ни в JavaConfig. Например, для одноэлементных java-бинов без сохранения состояния, которые просто нужно подключить к другим классам (в идеале через интерфейс), этот подход работает очень хорошо. В общем, для Spring beans я по большей части отошел от Spring XML DSL для определения bean-компонентов и теперь предпочитаю использовать JavaConfig и Spring Annotations, потому что вы получаете некоторую проверку конфигурации во время компиляции и некоторую поддержку рефакторинга, которую вы не делаете. не получить с конфигурацией Spring XML. Я смешиваю их в некоторых редких случаях, когда обнаружил, что JavaConfig / Annotations не может делать то, что доступно с использованием конфигурации XML.

Для Hibernate ORM (еще не использовал JPA) я по-прежнему предпочитаю файлы сопоставления XML, потому что аннотации в классах модели предметной области в некоторой степени нарушают The Clean Architecture которая представляет собой многоуровневый архитектурный стиль, который я принял за последние несколько лет. Нарушение происходит потому, что он требует, чтобы базовый уровень зависел от вещей, связанных с сохранением, таких как библиотеки Hibernate или JPA, и это делает POJO модели предметной области немного менее игнорирующими постоянство. Фактически основной уровень вообще не должен зависеть от какой-либо другой инфраструктуры.

Однако, если «Чистая архитектура» - не ваша «чашка чая», то я вижу определенные преимущества (такие как удобство и ремонтопригодность) использования аннотаций Hibernate / JPA в классах модели предметной области по сравнению с отдельными файлами сопоставления XML.