Стандартный рабочий процесс при работе с JPA

Question

Я сейчас пытаюсь обернуться вокруг работы с JPA. Я не могу помочь, но чувствую, что что-то упустил или делаю это неправильно. Пока что это кажется вынужденным.

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

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

Кажется, у обоих есть недостатки, и есть преимущества у обоих (как и у всех вещей). Мой вопрос в идеальной ситуации: каков стандартный рабочий процесс с JPA? Большинство схем требуют обновлений на этапе обслуживания и особенно на этапе разработки, так как же это обрабатывается?

Answer 1

Не всегда хороший подход для генерации схемы БД из аннотированных сущностей. Хотя в теории это звучит замечательно - на практике часто генерируемая схема не является оптимальной и не удовлетворяет и опытного администратора баз данных.

Подход, которым я следую в своем рабочем процессе, заключается в создании сущностей и схемы БД отдельно, при этом все еще используется довольно интеллектуальный инструмент для создания схемы - либо что-то вроде Liquibase , который не зависит от базы данных, поддерживает ревизии, откаты и т. д. ... или пользовательский запеченный инструмент миграции, который просто выполняет сильно оптимизированные специфичные для БД сценарии sql.

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

Однако я могу быть полезен для генерации схемы из объектов для тестовой базы данных, в отношении которых выполняются модульные и интеграционные тесты. Предполагая, что вы используете, скажем, PostgreSQL - производственный процесс, вы можете решить ускорить выполнение модульных тестов, запускающих некоторую встроенную базу данных в памяти, например H2, которая создается из сущностей до запуска тестов и автоматически исчезает (поскольку она была в памяти). ) после завершения испытаний. Это очень распространенная практика.

Answer 2

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

Что должно произойти, это проект по переходу на JPA. В этом есть несколько преимуществ:

• Бизнес-логика удалена со слоя базы данных (который сложнее масштабировать по горизонтали) на уровень приложения.
• Java-разработчики, как правило, дешевле, чем DBA. Хотя вам все еще нужен кто-то, кто умеет мыслить как по базам, так и по Java, чтобы делать это правильно, и это случается реже.
• Сокращая базу данных до простого хранилища данных, вы можете избавиться от блокировки поставщика.
• Если все сделано правильно, вы можете иметь другую базу данных для разработки (может быть DB2 Express C, которая является бесплатной) и иметь более надежную базу данных для ваших интеграционных и производственных сред (например, DB / 2 для zOS). Это позволяет иметь больше разработчиков, не беспокоясь о затратах на лицензирование.

Что касается генерируемых схем и т. Д., На самом деле может быть четыре рабочих процесса:

1. Для проектирования диаграмма Object-Relational (а не Entity-Relational) служит контрактом между командой приложения и командой базы данных. Конечный результат - объекты JPA будут работать в физической структуре данных, которую устанавливает DBA.
2. Для разработки приложений на Java, просто дайте каждому разработчику иметь свою собственную базу данных и дайте им взорвать ее столько, сколько они захотят. Код JPA сгенерирует схемы для вас.
3. Для разработки базы данных сгенерированные схемы и диаграммы классов передаются на рассмотрение администратору базы данных, чтобы увидеть, где можно улучшить производительность. В частности, они предназначены для указания индексов, которые недоступны в стандарте JPA, поскольку он не является кросс-базой данных. Они также предназначены для настройки табличных пространств и всех элементов управления доступом и схем для разработки, но, по крайней мере, суть структуры можно у них отобрать и передать команде приложения, что дает команде приложения больше гибкости для адаптации. к изменениям. Что обычно происходит, если DBA просто включает в себя некоторые сгенерированные SQL, а затем имеет средства для добавления дополнительных столбцов и других, которые будут использоваться для других целей вне приложения (структура JPA нуждается только в том, что требуется приложению, в этом нет необходимости для сопоставления 100% один к одному с базой данных)
4. Для миграции администратору базы данных необходимо провести дифференциальный анализ между двумя схемами. Есть программа dbsolo (не бесплатная), которая может сделать это с большинством баз данных. Однако, если бы что-то было сделано в JPA, структуры были бы проще, поскольку в теории больше нет бизнес-логики в базе данных, что снижает сложность миграции данных из-за обновлений.

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

Answer 3

Как обычно, ответ зависит ...

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

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

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

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