В нескольких крупных проектах, над которыми я работал в последнее время, становится все более важным выбирать тот или иной (XML или аннотацию). По мере роста проектов последовательность очень важна для удобства обслуживания.
Мои вопросы: каковы преимущества конфигурации на основе XML по сравнению с конфигурацией на основе аннотаций и каковы преимущества конфигурации на основе аннотаций над конфигурацией на основе XML?
Аннотации используются, но они не являются одной серебряной пулей, чтобы убить XML-конфигурацию. Я рекомендую смешивать два!
Например, если вы используете Spring, интуитивно использовать XML для части приложения для инъекций приложения. Это заставляет зависимости кода от кода, который будет использовать его, напротив, используя какую-то аннотацию в коде, который нуждается в зависимостях, делает код осведомленным об этой автоматической конфигурации.
Однако вместо использования XML для управления транзакциями маркировка метода как транзакционного с аннотацией имеет смысл, так как это информация, которую программист, вероятно, захочет узнать. Но что интерфейс будет вводиться как подтип, а SubtypeX не должен быть включен в класс, потому что если теперь вы хотите ввести SubtypeX, вам нужно изменить свой код, тогда как у вас был контракт с интерфейсом до этого, так что с XML, вам просто нужно будет изменить сопоставления XML, и это довольно быстро и безболезненно.
Я не использовал аннотации JPA, поэтому я не знаю, насколько они хороши, но я бы сказал, что оставить отображение beans в базе данных в XML тоже хорошо, поскольку объект не должен заботиться откуда появилась его информация, нужно просто заботиться о том, что она может делать с ее информацией. Но если вам нравится JPA (у меня нет опыта с ним), непременно, идите на это.
В целом: Если аннотация предоставляет функциональность и сама по себе является комментарием и не связывает код с каким-то конкретным процессом, чтобы нормально функционировать без этой аннотации, перейдите к аннотациям. Например, транзакционный метод, помеченный как транзакционный, не убивает его логику работы и также служит хорошим комментарием кода. В противном случае эта информация, вероятно, лучше всего выражается как 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.
Важной частью использования подхода, основанного только на аннотациях, является то, что понятие "bean name" более или менее уходит (становится несущественным).
"bean names" в Spring формирует дополнительный уровень абстракции над классами реализации. С XML beans определены и указаны относительно их имени 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 и С# [Attribute]) являются параметрами времени компиляции, а XML - временем выполнения. Это для меня говорит, что они не эквивалентны и имеют разные плюсы и минусы.
Я также считаю, что смесь - лучшая вещь, но она также зависит от типа параметров конфигурации. Я работаю над проектом Seam, который также использует Spring, и я обычно развертываю его на разных серверах разработки и тестирования. Итак, я разделил:
Главное отличие заключается в том, что вам не нужно перекомпилировать код для всех изменяющихся конфигураций для сервера, просто отредактируйте файл xml. Также преимущество в том, что некоторые изменения конфигурации могут быть сделаны членами команды, которые не понимают весь задействованный код.
В области контейнера DI я рассматриваю DI, основанный на аннотации, злоупотребляя использованием аннотации Java. Говоря это, я не рекомендую широко использовать его в вашем проекте. Если вашему проекту действительно нужна мощность контейнера DI, я бы рекомендовал использовать Spring IoC с настройкой конфигурации на основе Xml.
Если это всего лишь ради Unit-теста, разработчики должны применять шаблон Injection Inject в своем кодировании и использовать преимущества от насмешливых инструментов, таких как EasyMock или JMock, чтобы обойти зависимости.
Вы должны стараться избегать использования контейнера DI в неправильном контексте.
Конфигурационная информация, которая всегда будет связана с конкретным компонентом Java (класс, метод или поле), является хорошим кандидатом для представления аннотациями. Аннотации работают особенно хорошо в этом случае, когда конфигурация является основной для цели кода. Из-за ограничений аннотаций это также лучше, когда каждый компонент может иметь только одну конфигурацию. Если вам нужно иметь дело с несколькими конфигурациями, особенно теми, которые обусловлены чем-либо вне класса Java, содержащим аннотацию, аннотации могут создавать больше проблем, чем они решают. Наконец, аннотации не могут быть изменены без повторной компиляции исходного кода Java, поэтому все, что нужно переконфигурировать во время выполнения, не может использовать аннотации.
Пожалуйста, ознакомьтесь со следующими ссылками. Они также могут быть полезны.
Это классический вопрос "Конфигурация против Конвенции". В большинстве случаев личный вкус диктует ответ. Однако лично я предпочитаю конфигурацию (т.е. Основанную на XML) по Конвенции. ИМО IDE достаточно надежны, чтобы преодолеть некоторые из адских людей XML, которые часто ассоциируются с построением и поддерживают подход на основе XML. В конце концов, я нахожу, что преимущества Конфигурации (например, создание служебных программ для сборки, поддержки и развертывания файла конфигурации XML) в долгосрочной перспективе перевешивают Конвенцию.
Я использую оба. В основном XML, но когда у меня есть куча beans, которые наследуются от общего класса и имеют общие свойства, я использую аннотации для тех, в суперклассе, поэтому мне не нужно устанавливать одинаковые свойства для каждого bean, Поскольку я немного управляющий, я использую @Resource (name= "referBean" ) вместо того, чтобы просто загружать вещи (и сэкономить много неприятностей, если мне понадобится еще один bean того же класса, что и оригинал referBean).
Из моего опыта есть некоторые плюсы и минусы настройки аннотации:
Я предпочитаю комбинировать оба подхода - аннотации java и необходимый минимальный xml, который сводит к минимуму конфигурацию ада.
Для 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.