Каковы преимущества/недостатки аннотаций (не компилятор) по сравнению с xml-конфигурационными файлами

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

Я с интересом спрашиваю себя, как мне идти.

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

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

Итак, когда я смотрю на мои очки, я склонен идти по xml-пути. Но при просмотре форумов или руководств обычно используются аннотации.

Каковы ваши плюсы и минусы?

Ответ 1

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

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

Сосредоточьтесь на гибкости и удобочитаемости.

Ответ 2

Если вы пишете API, то слово предупреждения: аннотации могут просачиваться в ваш публичный интерфейс, который может быть невероятно бесит.

В настоящее время я работаю с API, где поставщик API наполнил его реализацию аннотациями Spring MBean, что внезапно означает, что я зависим от библиотек Spring, несмотря на то, что мне, возможно, не нужно будет использовать Spring вообще: (

(Конечно, если ваш API был расширением до самого Spring, это может быть допустимым предположением.)

Ответ 3

Я думаю, что решение сводится к "жизненному циклу" и несоответствию импеданса между жизненными циклами.

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

Предположим, что я помещаю аннотации Hibernate в класс Java. Похоже на разумную идею, особенно если я создаю новую базу данных с нуля и уверен, что только одно приложение когда-либо подключится к ней - жизненные циклы моих классов, схема базы данных и сопоставление ORM, естественно, синхронизируются.

Теперь предположим, что я хочу использовать тот же самый класс в API и передавать его третьим лицам. Аннотации Hibernate просачиваются в мой API. Это происходит потому, что жизненный цикл этого класса и базы данных - это не одно и то же. Поэтому мы используем инструменты отображения для перевода между слоями beans в системе.

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

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

Примеры безвредных аннотаций: Определения конечных точек REST, сериализация JSON/XML, проверки, которые всегда применяются.