А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.
Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
Ну, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.
Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
И как аннотация @Columnспасет от проблем при, например, переименовании поля в базе? Никак - либо поле в entity переименуется вслед за полем таблицы, что поломает внешнее апи в том случае если энтити выдается потребителю наружу, либо поле в энтити будет называться не так, как называется поле в БД, что вызовет массу вопросов у тех, кто будет поддерживать код. Эй, ребят, а вы не знаете, почему у нас поле в котором лежит отчество называется name? А, это что б потребителям контракт не сломать... Эх, была бы промежуточная dto на которой можно было бы разрулить проблему маппинга!
Честно говоря не пойму почему возврат сущностей из БД в rest выдаче для CRUD сервисов - это антипаттерн
Потому что переименование поля в таблице - сугубо внутреннее действие - ломает внешнее api. Потому что добавление поля в таблицу - сугубо внутреннее действие - делает его доступным внешнему api. Иными словами любое действие над нутрянкой может негативно сказаться на внешнем контракте - потому и антипаттерн.
Работал "рядом" с проектом, где так и декларировали. Проблема была, что бэкенд был, без модных наваротов, типа перекладываения данных по DTO. Берёшь из базы передаёшь на фронтенд. Поменял поле, фронт отвалился.
Но это не "модные навороты", уже сто лет есть конвертеры, которые все это делают за программиста. Например тут: https://modelmapper.org/getting-started/ Эта либа как раз предназначена для безпроблемного перегона entity в dto, хотя ее можно использовать буквально что б что угодно в что угодно конвертить. То есть в процитированном случае был не "бэк без новомодных фишек", а, простите, "джунов посадили писать проект и они сделали, как показывали на курсах от скиллбокса" со всеми вытекающими.
Обычно все просто - если есть разлапистый фронтенд, на котором отдельная команда лепит всякие графики, градусники и прочие статусбары, в отрыве от всего остального мира, то имеет смысл отдавать на фронт весь датасет, и пусть уже фронт разбирается какую его часть и в каком виде показать пользователю. Если же данных много, и пропихивать их через сеть все разом не рационально, то обработка происходит на сервере.
В реальной жизни, как правило, я сталкивался с чем-то средним - на сервере датасет грубо ограничивается до каких-то вменяемых размеров, а тонкая фильтрация происходит уже на клиенте, за счет чего пользователь испытывает счастье от отзывчивого интерфейса и ощущения "информации на кончиках пальцев".
А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
JPA/ORM это не про то, чтобы не думать об sqlНу, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
А давно эрланг стал интерпретируемым?
А почему приговор-то?
Очередная поделка в попытке проехаться на нетленке Остера? Почему-то я не удивлен.
В Sublustrum разве что атмосферная коммуналка в сталинке, а дальше просто шиза.
Работает точно так же - в качестве зависимости внедряется ссылка на один и тот же объект.
Разработчики на Spring:
- Синглтон зло? Ух ты!
Краткая суть - у них распродажа, поэтому случайный текст и ссылка.
Вот потому и антипаттерн, что приходится выбирать между двумя плохими решениями.
И как аннотация @Columnспасет от проблем при, например, переименовании поля в базе? Никак - либо поле в entity переименуется вслед за полем таблицы, что поломает внешнее апи в том случае если энтити выдается потребителю наружу, либо поле в энтити будет называться не так, как называется поле в БД, что вызовет массу вопросов у тех, кто будет поддерживать код. Эй, ребят, а вы не знаете, почему у нас поле в котором лежит отчество называется name? А, это что б потребителям контракт не сломать... Эх, была бы промежуточная dto на которой можно было бы разрулить проблему маппинга!
Честно говоря не пойму почему возврат сущностей из БД в rest выдаче для CRUD сервисов - это антипаттернПотому что переименование поля в таблице - сугубо внутреннее действие - ломает внешнее api. Потому что добавление поля в таблицу - сугубо внутреннее действие - делает его доступным внешнему api. Иными словами любое действие над нутрянкой может негативно сказаться на внешнем контракте - потому и антипаттерн.
Ощущение, что статью создали при помощи генератора случайного текста.
Работал "рядом" с проектом, где так и декларировали. Проблема была, что бэкенд был, без модных наваротов, типа перекладываения данных по DTO. Берёшь из базы передаёшь на фронтенд. Поменял поле, фронт отвалился.Но это не "модные навороты", уже сто лет есть конвертеры, которые все это делают за программиста. Например тут: https://modelmapper.org/getting-started/ Эта либа как раз предназначена для безпроблемного перегона entity в dto, хотя ее можно использовать буквально что б что угодно в что угодно конвертить. То есть в процитированном случае был не "бэк без новомодных фишек", а, простите, "джунов посадили писать проект и они сделали, как показывали на курсах от скиллбокса" со всеми вытекающими.
Обычно все просто - если есть разлапистый фронтенд, на котором отдельная команда лепит всякие графики, градусники и прочие статусбары, в отрыве от всего остального мира, то имеет смысл отдавать на фронт весь датасет, и пусть уже фронт разбирается какую его часть и в каком виде показать пользователю. Если же данных много, и пропихивать их через сеть все разом не рационально, то обработка происходит на сервере.
В реальной жизни, как правило, я сталкивался с чем-то средним - на сервере датасет грубо ограничивается до каких-то вменяемых размеров, а тонкая фильтрация происходит уже на клиенте, за счет чего пользователь испытывает счастье от отзывчивого интерфейса и ощущения "информации на кончиках пальцев".
Детали внутренней реализации протекают наружу, а значит, что внутренний рефакторинг или доработка на раз-два поломают внешнее апи.
Наоборот - я ниразу не видел работодателейЗначит вас можно просто не слушать, поскольку кругозор у вас весьма ограниченный, и это не попытка оскорбить, а непреложный факт.