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

в 7:00, , рубрики: java, jpa-buddy, spring framework, Блог компании Reksoft, генерация кода, Программирование, Разработка веб-сайтов

Добрый день, уважаемый читатель ! Меня зовут Вартанян Артур, и я являюсь Java-разработчиком в компании “Рексофт”. Совсем недавно мне под руку попался плагин, который помогает генерировать код при написании программ - это JPA Buddy. В этой статье я не буду транслировать официальную документацию проекта или показывать на примере видеороликов, как нужно с ним работать, а приведу примеры своих рабочих кейсов, где плагин действительно выручил и сэкономил мое время. Спойлер: в создании POJO-классов, репозиториев для тучи сущностей, DTO-классов.

Иллюстрация © GOLTS
Иллюстрация © 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 проблемных пункта, которые я описал выше. А именно:

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

    Есть два пути создания POJO-классов через плагин:

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

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

      Создание через UI или с помощью готовых таблиц из базы данных
      Создание через UI или с помощью готовых таблиц из базы данных

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

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

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

Создание репозитория для сущности через UI
Создание репозитория для сущности через UI
  • Создание DTO-классов:

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

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

Генерация DTO исходя из полей сущности(с поддержкой от MapStruct)
Генерация DTO исходя из полей сущности(с поддержкой от MapStruct)
  • Создание FlyWay миграций, исходя из существующих классов:

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

Создание FlyWay миграций через UI(исходя из POJO-класса или из таблицы)
Создание FlyWay миграций через UI(исходя из POJO-класса или из таблицы)

Вывод:

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

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

Автор: Артур Вартанян

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js