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

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

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

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

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

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

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

Используя @Autowire, @Element, чтобы указать структуру, что делать с классом, полезно использовать аннотации.

Ввод URL-адреса в аннотацию @Webservice - это плохой стиль.

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

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

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

• Использование пространства имен "aop" для всех AOP. Это действительно отлично работает. Я по-прежнему использую его для транзакций, потому что размещение @Transactional по всему месту является своего рода перетаскиванием. Вы можете создавать именованные точки для методов в любой службе или репозитории и очень быстро применять рекомендации.

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

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

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

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

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

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

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

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

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

Это зависит от вас, что более важно...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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