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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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