Вопросы Теги

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

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

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

130
задан 30.04.2019, 22:51

9 ответов

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

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

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

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

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

197
ответ дан 06.10.2019, 10:18

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

1
ответ дан 06.10.2019, 10:18

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

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

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

3
ответ дан 06.10.2019, 10:18

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

1
ответ дан 06.10.2019, 10:18
  • 1
    Я думаю ' Конфигурация по сравнению с Convention' является ортогональным к этой проблеме. И Аннотации и XML-файлы имеют много разумных значений по умолчанию (конвенция), которые значительно упрощают их использование. Реальной разницей является время компиляции по сравнению со временем выполнения и в коде по сравнению с из кода. – HDave 03.02.2010, 17:02
  • 2
    ДА! Это было моей проблемой и включением, которое добился цели iCloud на Всем идентификаторе Приложений. Большое спасибо – Guy Moreillon 10.11.2019, 04:46

Я мог бы быть неправым, но я думал, что Аннотации (как в @Tag и C# Java [Атрибут]) были опцией времени компиляции, и XML был опцией во время выполнения. Это мне говорит, что не эквивалентный и имеет различные за и против.

3
ответ дан 06.10.2019, 10:18
  • 1
    То, что аннотации являются вещью времени компиляции, является про из основанной на аннотации конфигурации, однако обе аннотации и xml являются методами для конфигурации, и в этом контексте они достигают того же самого. например, конфигурирование в спящем режиме отображения в XML-файле в противоположность использованию аннотаций на класс. – abarax 08.10.2008, 15:36
  • 2
    А-а-а, я вижу свой беспорядок. Вопрос вводит в заблуждение меня, чтобы думать, что он описывал конфигурацию данных выше и вне просто метаданных класса. – ARKBAN 08.10.2008, 18:17

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

  • плюс: аннотации менее болтливы
  • минус: аннотации менее видимы

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

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

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

4
ответ дан 06.10.2019, 10:18

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

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

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

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

Помещение URL в @Webservice аннотация является плохим стилем.

, Но это - просто мое мнение. Путь между взаимодействием и конфигурацией не всегда свободен.

13
ответ дан 06.10.2019, 10:18
  • 1
    Это было моим ключом здесь! Я проверил обоих и Целевые Настройки Сборки Проекта. В разделе Code Signing существует установка " Подписывание кода Entitlements" - я развернул, выделил обоих строки отладки и выпуска и нажал клавишу Delete. Это тогда позволило моему приложению создавать без любых ошибок. Однако это все еще won' t отладка - это сразу выходит с сообщением в консоли, я должен буду искать его. – Jay Imerman 10.11.2019, 04:50

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

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

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

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

6
ответ дан 06.10.2019, 10:18

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

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

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

5
ответ дан 06.10.2019, 10:18

Теги

Похожие вопросы