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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я использую 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для 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, потому что аннотации в классах модели предметной области в некоторой степени нарушают Чистая архитектура, который является многоуровневым архитектурным стилем, который я принял за последние несколько лет. Нарушение происходит потому, что он требует, чтобы базовый уровень зависел от вещей, связанных с сохранением, таких как библиотеки Hibernate или JPA, и это делает POJO модели предметной области немного менее игнорирующими персистентность. На самом деле основной уровень вообще не должен зависеть от какой-либо другой инфраструктуры.

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