JPA: Должен ли я очистить свои классы сущностей, используя orm.xml?

Question

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

Я вижу, что DataNucleus рекомендует помещать связанные с ORM аннотации в XML вместо (окрашенные в розовый цвет), но я не видел, чтобы другие реализации рекомендовали это, и JPA, похоже, не разделяет аннотации в эти две группы (я думаю, что JDO делает).

Кто-нибудь использует аннотации + orm.xml таким образом, и каков ваш опыт?

Удалит ли он некоторые загрязнения из моих классов сущностей или у меня возникнут проблемы?

Answer 1

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

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

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

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

Answer 2

Сущности JPA, являющиеся просто Java Beans (классы, определяющие методы получения и установки) с необязательным вспомогательным кодом (конструкторы, hashCode, equals, именованные запросы, методы копирования, что еще?) Вряд ли можно считать загрязненными, даже если включены все типы комментариев JPA ,

Реальной целью разделения метаданных между аннотациями Java и xml было бы упрощение и оптимизация политик развертывания. Цена, которую вы понесете, будет двойной:

1. обеспечение развития политика в отношении того, что метаданные принадлежит к какому месту и
2. перекрестные ссылки на Java и XML при создании и особенно поддержание метаданных (более или менее, но всегда неудобство).

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

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