Comments 8
Если у вас есть соответствующая библиотека с реализацией crud то это не сотни строк кода, вам будет достаточно определить доменый объект и дто по желанию и все без AI. А так вам AI нагенерит кучу кода который беде лежать в репозитарии и за который придётся нести ответственность :)
Не очень понимаю про что ваш коммент.
А так вам AI нагенерит кучу кода который беде лежать в репозитарии и за который придётся нести ответственность :)
А вы точно прочитали статью до конца? Или ограничились вступлением и пошли писать комментарий?
достаточно определить доменый объект и дто по желанию и все без AI
Как раз именно это мы и пытаемся автоматизировать. Практически все наши Actions о которых идет речь в статье это элементарные операции преобразования из одного в другое. И генерация DTO по JPA модели яркое тому подтверждение о чем и рассказано в статье. Чтобы не набирать шаблонный код с нуля каждый раз.
И мы не пытаемся лезть в бизнес логику приложения, пользователь может сам писать ее как хочет, хоть руками с использованием своих любимых библиотек, хоть с помощью нашего AI ассистента.
Поэтому вообще не понятно о чем вы пишите.
Я думаю речь про тот же Jimmer. Jimmer убирает необходимость поддерживать бойлерплейт который ваш плагин радостно помогает генерить. Ну или jOOQ тоже нагенерит сам много и там LLM нужен только чтобы запросы писать. Ну в общем типичное
мы автоматизировали генерацию геттеров и сеттеров!
каких геттеров, у нас Котлин
мы автоматизировали генерацию геттеров и сеттеров
Почему вы заостряете внимаение только на одном моменте? Помимо это мы также генерируем
1) модель по SQL файлам
2) OpenAPI документацию из контроллеров и обратно
3) Конфиги Kafka/Security
4) http запросы из Postman/Curl
5) конвертация пропертей из разных форматов
И если даже говорить о геттерах и сеттерах, применимо к одной из самых популярных технологий на Spring - JPA, то хоть Java, хоть Kotlin - филды никуда не деваются. Или вам нравится писать их руками? Лично мне нет. И LLM прекрасно решает эту проблему также. Как и генерацию модели по SQL файлу. Не все фрейморки также как JOOQ умеют создавать модель по БД.
Тоже самое относится и к DTO. Kotlin филды за вас не напишет.
Я понимаю что Jimmer выглядит не очень понятным, но смотрите что генерирует тот же Jimmer:
entity classes by database tables
dtos
repositories
open api 3.0 crud rest -> из этого можно кодом нагенерить http запросы под любой движок: idea http client, postman, curl, etc
Json schema
В общем суть вы должны понять, это вполне себе конкретная задача, как получить геттеры/сеттеры или распарсить язык, а вы зачем-то хвастаетесь что написали промпт для LLM который это тоже делает (с какой-то вероятностью конечно)
Спасибо за пояснение.
а вы зачем-то хвастаетесь что написали промпт для LLM который это тоже делает
Мы не хвастаемся этим, а поясняем во вступлении к статье, что это очень дешевый способ получения нужного функционала, который достигается путем интеграции двух наших плагинов. И как вы правильно заметили с определенной долей вероятности, о чем мы также пишем в статье, что те же конфиги скорее всего придется дорабатывать руками.
Но спасибо за наводку, не скрою, я только мельком слышал про данный фрейморк, может быть в дальнейшем стоить разобраться с ним более подробно и получится затащить часть функционала без ИИ.
Из статьи не увидел некоторых моментов:
1) как будет работать маппер не entity/dto, что довольно примитивно само по себе и тоже не является хорошей практикой, а связка dto-доменный объект (агрегирующий другие доменные объекты и объекты-значения)-entity.
2) моделька используется локальная? Или пользовательская кодобаза таки утекает через такой плагин?
1) тут нет никаких чудес - все зависит от модели которую использует LLM. И как правильно заметили выше делает это с опрделенной степенью вероятности. Основный посыл в том что мы генерим базойвый boilerplate код который гораздо проще доработать руками до нужного состоянии, чем писать руками, даже если LLM не совсем корректно справилась, о чем мы такжу упомянули в статье. Я сделал небольшой пример по вашему сценарию (скрины прикреплю ниже). Так наша дефолтная модель которую можно использовать в персональной подписке (первый месяц бесплатно), увидела что внутри есть вложенные объекты и спросила надо ли сделать для них тоже "ентити".
2) модель используется та которую вы выберете в настройках Explyt плагина. Более подробно можно прочитать тут. Поддержка локальных моделей тоже есть.
Нейросети в Spring-разработке: убираем рутину, а не интеллект