Почему люди продолжают использовать файлы сопоставления xml вместо аннотаций?

Я заметил странный факт (основанный на вопросах в теге hibernate), что люди все еще активно используют xml файлы вместо аннотаций, чтобы указать их сопоставления ORM (Hibernate/JPA).

Есть несколько случаев, когда это необходимо:

вы используете классы, которые предоставляются, и вы хотите их сопоставить.
вы пишете API, чьи классы домена могут использоваться без поставщика JPA, поэтому вы не хотите принудительно устанавливать зависимость JPA/Hibernate.

Но это не обычные случаи, я думаю.

Мои предположения:

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

Любые другие возможные объяснения?

Ответ 1

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

Ответ 2

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

Ответ 3

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

А, но это не так. Три случая с верхней части головы (возможно, больше) вы не можете сделать (ну) с аннотациями:

Используйте формулу как часть ключа ассоциации (правда, скорее эзотерический).
Join-through-subselect - @Loader не является адекватной заменой. Не слишком общий, но весьма полезный. Envers обеспечивает жизнеспособный альтернативный подход.
Потеря порядка столбцов для генерации схемы. Это абсолютный убийца. Я понимаю, почему это так, но это все равно досаждает мне до конца.

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

Итак, если вы хотите развернуть свой класс в нескольких хранилищах данных. И вы хотите аннотировать определения столбцов в нем? Различные хранилища данных имеют разные соглашения и т.д., И использование XML - единственное нормальное место в этой ситуации, возможность иметь один для MySQL и один для Derby, а другой для Oracle или что-то еще. В этом случае вы можете поместить основные аннотации сохранения/отношения, если хотите, но специфичный для схемы материал пойдет в XML в этом случае.

- Энди (DataNucleus)

Ответ 7

Некоторая информация хорошо переносится в аннотациях, таких как мощность отношений между объектами. Эти аннотации предоставляют более подробную информацию о самой модели, а не о том, как модель относится к чему-то еще.

Однако привязки, будь то хранилище сохранения или XML или что-то еще, являются внешними для модели. Они меняются в зависимости от контекста, в котором используется модель. Включение их в модель так же плохо, как использование встроенных определений стиля в HTML. Я использую внешние привязки (обычно XML-документы, но не обязательно), по тем же причинам ссылаюсь на внешний CSS.

Ответ 8

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

Ответ 9

У меня есть новый: http://www.summerofnhibernate.com/

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

Ответ 10

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

Поэтому, когда вы хотите изменить/настроить конфигурацию по умолчанию, это проще сделать в XML файле по сравнению с выполнением аннотаций.

Ответ 11

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

Ответ 12

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