Hibernate Tools и постоянно меняющаяся база данных

Question

В настоящее время я использую Hibernate Tools 3.1; Я настроил соглашение об именах и шаблоны DAO. База данных (SQL Server 2005) на ранней стадии разработки, и я отвечаю за восстановление сопоставлений, сущностей, DAO, конфигурации, что угодно. Каждый раз, когда я должен перепроектировать таблицы, и поэтому я потерять все настройки я сделал на отображениях (* .hbm.xml файлы), как Регулировка тождеству столбцов, выбирая поля, используемые в равен и ToString. Я подумывал написать diff XML в файле и «merge», что на сгенерированном сопоставлении (см. my related question), но мне было интересно ... есть ли лучшая практика/инструмент для решения этих досадных, неизбежных и важных задач?

Answer 1

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

Мы используем миграции для управления изменениями db, и мы включаем связанные изменения в hbm. Если у Hibernate есть (я полагаю, что это так), вы можете захотеть просмотреть аннотации вместо hbm, их можно будет немного упростить.

Answer 2

Это два с половиной годами позже, но я предлагаю особое мнение. Вы должны иметь возможность делать любые настройки, необходимые для файлов сопоставления, через файл hibernate.reveng.xml или пользовательскую ReverseEngineeringStrategy. Для самих классов вы всегда должны генерировать базовые классы и расширять их с помощью классов, содержащих пользовательский код.

Например, сгенерируйте com.company.vo.generated.CustomerGenerated и расширьте его с помощью com.company.vo.custom.Customer. Генерация кода должна перезаписывать все классы в сгенерированном пакете, но никогда в пользовательском пакете (хотя вы можете заставить Hibernate Tools генерировать эти пользовательские классы в целевом каталоге, чтобы при необходимости копировать и вставлять пробелы в настраиваемый каталог). Таким образом, вы можете переопределить методы для equals, toString и т. Д. В пользовательских классах и не потерять свои изменения при регенерации. Также обратите внимание, что наилучшей практикой является не проверка сгенерированного кода в SCM.

На этом сайте есть несколько отличных примеров того, как достичь этого, используя Maven, плагин Hibernate3 и плагин поддержки сборки. Большинство из них имеют очень полезные ответы Паскаля Тивена. Этот метод прекрасно работает для меня, и хотя есть немного кривая обучения, это замечательная вещь, чтобы иметь возможность распространять изменения в базе данных в приложении с помощью одной команды Maven.