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

130
задан Eduardo 30 April 2019 в 19:51
поделиться

12 ответов

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

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

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

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

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

197
ответ дан MetroidFan2002 30 April 2019 в 19:51
поделиться

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

3
ответ дан ARKBAN 30 April 2019 в 19:51
поделиться

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

1
ответ дан Jason 30 April 2019 в 19:51
поделиться
  • 1
    ДА! Это было моей проблемой и включением, которое добился цели iCloud на Всем идентификаторе Приложений. Большое спасибо – Guy Moreillon 19 August 2013 в 08:50

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

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

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

3
ответ дан Cristian Vat 30 April 2019 в 19:51
поделиться

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

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

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

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

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

4
ответ дан Juraj 30 April 2019 в 19:51
поделиться

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

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

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

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

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

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

13
ответ дан Rohit Gaikwad 30 April 2019 в 19:51
поделиться
  • 1
    Это было моим ключом здесь! Я проверил обоих и Целевые Настройки Сборки Проекта. В разделе Code Signing существует установка " Подписывание кода Entitlements" - я развернул, выделил обоих строки отладки и выпуска и нажал клавишу Delete. Это тогда позволило моему приложению создавать без любых ошибок. Однако это все еще won' t отладка - это сразу выходит с сообщением в консоли, я должен буду искать его. – Jay Imerman 24 July 2012 в 20:04

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

1
ответ дан Chochos 30 April 2019 в 19:51
поделиться

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

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

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

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

6
ответ дан cliff.meyers 30 April 2019 в 19:51
поделиться

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

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

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

5
ответ дан krosenvold 30 April 2019 в 19:51
поделиться

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

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

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

30
ответ дан 24 November 2019 в 00:16
поделиться

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

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

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

5
ответ дан 24 November 2019 в 00:16
поделиться

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

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

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

2
ответ дан 24 November 2019 в 00:16
поделиться
Другие вопросы по тегам:

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