Добрый день, уважаемый читатель Хабра! Меня зовут Вартанян Артур, и я являюсь Java-разработчиком в компании “Рексофт”. Совсем недавно мне под руку попался плагин, который помогает генерировать код при написании программ - это JPA Buddy. В этой статье я не буду транслировать официальную документацию проекта или показывать на примере видеороликов, как нужно с ним работать, а приведу примеры своих рабочих кейсов, где плагин действительно выручил и сэкономил мое время. Спойлер: в создании POJO-классов, репозиториев для тучи сущностей, DTO-классов.
Кому будет полезна данная статья?
Если Вы опытный разработчик, которому часто приходится работать с сущностями, писать для них 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 проблемных пункта, которые я описал выше. А именно:
Создание POJO-классов:
Есть два пути создания POJO-классов через плагин:
Генерация из уже существующих таблиц.
Генерация через UI, где мы можем указывать только названия полей и их типы (при этом в один клик добавляя нужные аннотации).
Создание через UI или с помощью готовых таблиц из базы данных Мне сильно повезло, ведь я как “добросовестный программист” собрал базу данных вручную, и она уже была готова. Затем я воспользовался быстрой генерацией, исходя из таблиц БД, и за минуту все 15 классов были созданы и помечены аннотациями для ORM.
Создание репозитория для каждой сущности:
Плагин также поддерживает генерацию репозиториев. Все что нужно - это указать сущность, для которой мы генерируем репозиторий, название репозитория и тип репозитория из целого списка (пример CrudRepository или JpaRepository).
Создание DTO-классов:
Логика абсолютно такая же, как и в предыдущих действиях. Создаем DTO, указываем исходный класс, даем название новому классу и выбираем нужные поля для трансфера.
Одно из самых больших преимуществ - это поддержка библиотеки MapStruct, которая выступает в роли маппера. Достаточно добавить ее зависимости к себе в проект, и при последующем создании DTO у вас высветится поле с явным созданием маппера.
Создание FlyWay миграций, исходя из существующих классов:
В целом JPA-Buddy предоставляет обширный круг возможностей для работы с миграциями: создание Java-миграций, генерация SQL-скриптов, JSon-представлений для баз данных и т.д. Например, создав пустой файл с .sql расширением, можно автоматически генерировать скрипты для таблиц, колонок и индексов.
Вывод:
JPA-Buddy действительно мощный инструмент, который заметно облегчает жизнь разработчику, избавляя его от рутинной работы, не считая того, что был рассмотрен далеко не весь функционал плагина. Для меня в первую очередь - это экономия времени и возможность за короткий срок собрать решение, если под рукой отсутствует ready-made-solution.
Спасибо за внимание! Надеюсь данная статья была полезна для вас!
