Открыть список
Как стать автором
Обновить

Комментарии 12

Все это хорошо пока не дойдешь до динамических запросов с несколькими параметрами, на что есть два решения: QueryDSL и JPA Specifications.
QueryDSL, как я понял, малопопулярен. Но во обоих случаях придется писать довольно много кода, что сравнимо с Criteria API. Тогда зачем еще один уровень абстракции, если можно это сделать со старым, добрым Criteria API? Что я и стал пока делать.


Может скажет, что "JPA Specifications" все-таки правильный путь?
Статья Using Spring Data JPA Specification как-то малоубедительна.

Вовсе не исключаю возможности использования Criteria Api, но для массовых простых операция декларативный подход очень даже.

Используем QueryDSL, довольны.

Тут вопрос о не исключительность Sprint data, а как о некоем фасаде между сущностью и прикладной логикой, а внутри репозитория думаю найдется место и Criteria
Мне в большинстве случаев хватало native query.
Из-за этого кончено репозиторий становился сильнее привязан к конкретной БД.
Зато не надо ломать голову с Criteria API. Более не удобного способа работы с БД я еще не встречал :-)
В Criteria был сделан упор на типизацию, на выявление ошибок еще на этапе компиляции, это видимо сделало его несколько сложным
ИМХО просто «странно» спроектированная «фигня».
Как минимум в PostgreSQL начиная с 8 версии типизация строгая.
Помню, когда переходил с 7-ой на 8-ю это доставило некоторое количество WTF-моментов
Каким образом native query помогает решить проблему «динамических запросов с несколькими параметрами»?
Тем, что не надо писать динамические запросы с несколькими параметрами. ;-)
Точнее, можно оформить в виде репозитария несколько запросов с разными параметрами, собрав их из нескольких SQL-кусков.
Все это хорошо пока не дойдешь до динамических запросов с несколькими параметрами

Основная проблема в том, что мы хотим по-возможности иметь type-safe queries. А все эти искусственные findBy*() или Query не решают проблемы. Интерфейс Repository начинает мешать, когда число сущностей становится несколько десятков, а модель данных не такая тривиальная. Кроме того, эстетически findFirst5ByFirstNameStartsWithOrderByFirstName() читается в десять раз хуже, чем обычный хорошо оформленный JPQL-запрос, особенно если для этого используется какой-нибудь QueryDSL или Criteria API.


QueryDSL, как я понял, малопопулярен

Очень даже популярен, до сих пор живет и релизится. Правда не так активно. Criteria API уродливый и жутко неудобный (как впрочем и большинство стандартизированных API). Могу порекомендовать замечательную библиотеку Jinq, где критерии задаются ввиде обычных джавовских лямбд. Не надо кодогенерации и искусственного DSL.


Тогда зачем еще один уровень абстракции

А это политика Spring-а — влезть посредником во все, что только возможно, там где нужно и ненужно, чтобы пользователи вообще не мыслили разработку без спринга.

Спасибо за Jinq, вижу стоит попробовать.

Ничего не мешает. :-)
Пишешь native query и получаешь удобство декларативного SQL.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.