JPA-Buddy — избавляемся от рутины. Практические кейсы
Добрый день, уважаемый читатель Хабра! Меня зовут Вартанян Артур, и я являюсь Java-разработчиком в компании «Рексофт». Совсем недавно мне под руку попался плагин, который помогает генерировать код при написании программ — это JPA Buddy. В этой статье я не буду транслировать официальную документацию проекта или показывать на примере видеороликов, как нужно с ним работать, а приведу примеры своих рабочих кейсов, где плагин действительно выручил и сэкономил мое время. Спойлер: в создании POJO-классов, репозиториев для тучи сущностей, DTO-классов.
Иллюстрация © GOLTS
Кому будет полезна данная статья?
Если Вы опытный разработчик, которому часто приходится работать с сущностями, писать для них POJO-классы, используя при этом Spring Boot и Spring Data JPA, то эта статья будет полезной. Я бы не советовал пользоваться плюшками данного плагина начинающему разработчику, так как JPA Buddy генерирует большое количество кода и помогает собирать программу на начальном этапе как детский конструктор, что делает некоторые важные базовые процессы для новичка непрозрачными и мотивирует его не тратить время на их изучение.
Какие проблемы меня преследовали?
Совсем недавно я спроектировал достаточно нестандартное WEB MVC-приложение. Оно должно было выступить у меня в роли pet-project«а для работы с новыми библиотеками и решениями. Нестандартно оно тем, что имеет в себе большое количество сущностей и соответствующее количество слоев для каждой сущности, то есть, имея 15 сущностей, мне нужно было создать как минимум 15:
POJO-классов и сделать разметку для ORM
Репозиториев для работы с JPA
Сервисов для бизнес-логики
DTO-классов
Rest-контроллеров для работы с сервисами
SQL-скриптов для FlyWay миграций
Вы спросите меня, по какой причине мне пришлось громоздить столько сущностей с таким количеством сервисов и контроллеров, и почему я не разработал уровень абстракции, который помог бы избежать большого количества кода? Любая абстракция со временем может начать проседать, так как приложение становится все больше и больше, и не всегда получается вписываться в рамки «обобщений». Поэтому тут выбор между: большим количеством кода (то есть временем его написания и трудоемкостью дальнейшей поддержки) и созданием абстракций, которые в дальнейшем придется «покрывать костылями», если вдруг окажется, что она не слишком хороша. Как по мне, так в первом варианте преимуществ больше. Да и случаев, когда выбор идет в сторону большого количества кода, прилично. Уверен, что найдутся те, кто не согласятся — понимаю и принимаю. Но это не повод не поделится моим опытом для тех, кому интересен JPA Buddy. Так что поехали.
После создания 3-го POJO-класса я понял, чтобы полностью расписать CRUD-методы приложения, придется потратить очень много времени, причем оно будет протекать максимально медленно, ведь работа в основном рутинная. Так было бы, если Intellij Idea в какой-то момент не порекомендовала мне включить плагин JPA-Buddy, который долгое время лежал у меня без дела.
Чем мне помог JPA-Buddy?
Вся прелесть данного плагина в том, что он без труда покрывает 4 из 6 проблемных пункта, которые я описал выше. А именно:
Создание репозитория для каждой сущности:
Плагин также поддерживает генерацию репозиториев. Все что нужно — это указать сущность, для которой мы генерируем репозиторий, название репозитория и тип репозитория из целого списка (пример CrudRepository или JpaRepository).
Создание репозитория для сущности через UI
Создание DTO-классов:
Логика абсолютно такая же, как и в предыдущих действиях. Создаем DTO, указываем исходный класс, даем название новому классу и выбираем нужные поля для трансфера.
Одно из самых больших преимуществ — это поддержка библиотеки MapStruct, которая выступает в роли маппера. Достаточно добавить ее зависимости к себе в проект, и при последующем создании DTO у вас высветится поле с явным созданием маппера.
Генерация DTO исходя из полей сущности (с поддержкой от MapStruct)
Создание FlyWay миграций, исходя из существующих классов:
В целом JPA-Buddy предоставляет обширный круг возможностей для работы с миграциями: создание Java-миграций, генерация SQL-скриптов, JSon-представлений для баз данных и т.д. Например, создав пустой файл с .sql расширением, можно автоматически генерировать скрипты для таблиц, колонок и индексов.
Создание FlyWay миграций через UI (исходя из POJO-класса или из таблицы)
Вывод:
JPA-Buddy действительно мощный инструмент, который заметно облегчает жизнь разработчику, избавляя его от рутинной работы, не считая того, что был рассмотрен далеко не весь функционал плагина. Для меня в первую очередь — это экономия времени и возможность за короткий срок собрать решение, если под рукой отсутствует ready-made-solution.
Спасибо за внимание! Надеюсь данная статья была полезна для вас!
