Стандартный Рабочий процесс при работе с JPA
Я в настоящее время пытаюсь перенести голову вокруг работы с JPA. Я не могу не чувствовать, что я пропускаю что-то или делаю его неправильный путь. Это просто кажется принудительным до сих пор.
Что я думаю, что знаю, до сих пор то, что их несколько способов работать с JPA и инструментами для поддержки этого.
- Можно сделать все в Java с помощью аннотаций и позволить JPA (безотносительно реализации, которую Вы решаете использовать), создают Вашу схему и обновляют его, когда изменения внесены.
- Можно использовать инструмент, чтобы перепроектировать Вас база данных и генерировать классы объекта для Вас. Когда схема обновляется, необходимо повторно создать эти классы или вручную обновить их.
Кажется, существуют недостатки обоим и преимущества для обоих (как со всеми вещами). Мой вопрос находится в идеальной ситуации, каков стандартный рабочий процесс с JPA? Большинство схем потребует обновлений в течение этапа технического обслуживания и особенно во время этапа разработки, поэтому как это обрабатывается?
2 ответа
Генерировать схему БД из аннотированных сущностей - не всегда хороший подход. Хотя в теории это звучит замечательно, на практике часто сгенерированная схема не является оптимальной и не удовлетворит опытного DBA.
Подход, которого я придерживаюсь в своем рабочем процессе, заключается в создании сущностей и схемы БД отдельно, при этом для создания схемы используется довольно интеллектуальный инструмент - либо что-то вроде Liquibase, который не зависит от базы данных, поддерживает ревизии, откаты и т.д... либо собственный инструмент миграции, который просто запускает сильно оптимизированные sql-скрипты, специфичные для БД.
Возможно, для вас это звучит менее чем идеально, но я могу заверить, что это сделает свою работу и сохранит ваш код, связанный со схемой, последовательным, поскольку, как указал Григорий, не все, связанное с базой данных, может быть сгенерировано из сущностей в любом случае.
Однако я могу быть полезен для генерации схемы из сущностей для тестовой базы данных, на которой выполняются модульные и интеграционные тесты. Предполагая, что вы используете, скажем, PostgreSQL, вы можете решить ускорить выполнение модульных тестов, запустив какую-нибудь встроенную базу данных в памяти, например H2, которая создается из сущностей до запуска тестов и автоматически исчезает (поскольку она была в памяти) после завершения выполнения тестов. Это очень распространенная практика.
Как обычно, ответ в том, что зависит от ...
Идеальный подход (в идеальном мире), вероятно, был бы вашим 1-м вариантом: поддерживать все, используя аннотации JPA и артефакты базы данных передового инженера с помощью служебного инструмента (например, используйте плагин Hibernate Maven ).
Это зависит от уровня поддержки артефактов вашей базы данных - не все принадлежит или подходит для аннотаций. Вот почему в моих проектах обычно используется параллельное обслуживание для обоих и использование модульных тестов для их синхронизации.
Это также зависит от доступных ресурсов. Если у вас есть специальный администратор базы данных, который отвечает за вашу базу данных, тогда будет иметь смысл делегировать ему обслуживание.
Еще одним соображением является то, насколько на самом деле разработка баз данных выполняется в JPA. Существуют ли также хранимые процедуры или другие приложения, отличные от JPA, которые используют тот же самый сервер, или, может быть, вы просто интегрируетесь с базой данных другой команды ...