JPA-Buddy — избавляемся от рутины. Практические кейсы

Добрый день, уважаемый читатель ! Меня зовут Вартанян Артур, и я являюсь 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-классов через плагин:

  1. Генерация из уже существующих таблиц.

  2. Генерация через UI, где мы можем указывать только названия полей и их типы (при этом в один клик добавляя нужные аннотации).

     

     Мне сильно повезло, ведь я как “добросовестный программист” собрал базу данных вручную, и она уже была готова. Затем я воспользовался быстрой генерацией, исходя из таблиц БД, и за минуту все 15 классов были созданы и помечены аннотациями для ORM.

• Создание репозитория для каждой сущности:

  Плагин также поддерживает генерацию репозиториев. Все что нужно - это указать сущность, для которой мы генерируем репозиторий, название репозитория и тип репозитория из целого списка (пример CrudRepository или JpaRepository).

• Создание DTO-классов:

  Логика абсолютно такая же, как и в предыдущих действиях. Создаем DTO, указываем исходный класс, даем название новому классу и выбираем нужные поля для трансфера.

  Одно из самых больших преимуществ - это поддержка библиотеки MapStruct, которая выступает в роли маппера. Достаточно добавить ее зависимости к себе в проект, и при последующем создании DTO у вас высветится поле с явным созданием маппера.

• Создание FlyWay миграций, исходя из существующих классов:

  В целом JPA-Buddy предоставляет обширный круг возможностей для работы с миграциями: создание Java-миграций, генерация SQL-скриптов, JSon-представлений для баз данных и т.д. Например, создав пустой файл с .sql расширением, можно автоматически генерировать скрипты для таблиц, колонок и индексов.

Вывод:

JPA-Buddy действительно мощный инструмент, который заметно облегчает жизнь разработчику, избавляя его от рутинной работы, не считая того, что был рассмотрен далеко не весь функционал плагина. Для меня в первую очередь - это экономия времени и возможность за короткий срок собрать решение, если под рукой отсутствует ready-made-solution.

Спасибо за внимание! Надеюсь данная статья была полезна для вас!