Comments 4
Опять сессия и студент прочёл first steps про spring data?
Specifications — это мощный инструмент для написания гибких запросов в Spring Data JPA. Они значительно упрощают работу с фильтрацией данных, заменяя громоздкие методы репозитория и улучшая читаемость кода.
Спецификации - хрень, которую можно красиво продать во всяких презентациях, на плоских сущностях. Для использования в реальных приложениях либо городятся костыли, либо свой аналог этих спецификаций, в которых эти костыли обыгрываются, чтобы наружу не торчали.
А в итоге, ничего лучше, чем прямая работа с EntityManager-ом не придумано.
Возможно, я ошибаюсь, но то, что Specifications не всегда подходят для сложных сценариев, не делает их "хренью". Это всего лишь инструмент, который удобно использовать, когда он подходит, и игнорировать, когда он избыточен.
Любое высокоуровневое решение действительно менее гибкое и может быть медленнее низкоуровневого. Однако высокоуровневые подходы, такие как Specifications, создаются для упрощения работы в типичных сценариях, где гибкость низкоуровневых решений не требуется.
С другой стороны, низкоуровневые инструменты, как вы верно заметили, позволяют тонкую настройку и лучше кастомизируются под нужды проекта. Но это не означает, что высокоуровневые решения бесполезны или не должны существовать. У каждого подхода есть свои задачи и сферы применения.
Specifications не всегда подходят для сложных сценариев, не делает их "хренью". Это всего лишь инструмент, который удобно использовать, когда он подходит, и игнорировать, когда он избыточен.
Вы как раз ошибаетесь. Вы в данном предложении мыслите "сиюминутно", простите, как студент, которому надо сделать что-то на раз и забыть.
Проблема большого интерпрайз-приложения в том, что ты не знаешь в каком месте оно станет сложным через ... скажем полгода. или год.
Приложения имеют тенденцию усложняться.
И когда ты понимаешь что "тут внезапно и неожиданно стало сложно", а "спецификации" уже превратили код в нечитаемый, неразбираемый, и - главное - неотлаживаемый кусок "чего-то" - любой чих в направлении отказа от этого "новомодномолодежного API" - будет стоит денег, нервов и новых багов. Потому что они "прописаны везде".
Отсюда - это как раз именно "хрень". Потому что она обманывает тебя красивой концепцией, а потом очень сильно и больно бьет, когда в реалььной жизни ты налетаешь на сложный случай с уже написанным кодом. Причем часто после того, как человек создавший это нагромождение - когда проект ещё был простым - уже не доступен.
Исходя из этого обстоятельства - есть один очень простой выход: запрет использования этого API на серьезных проектах.
Т.е. "на всех проектах сложнее "курсовой" которую можно стереть и забыть после сдачи зачета".
.
Построение динамических запросов к базе данных с использованием Spring Data JPA Specifications