arylkov Jan 7 2019 at 09:37

Spring Data JPA

9 min

324K

Comments 12

zesetup Jan 7 2019 at 14:15

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

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

arylkov Jan 7 2019 at 17:39

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

ruslanys Jan 7 2019 at 20:52

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

arylkov Jan 7 2019 at 21:01

Тут вопрос о не исключительность Sprint data, а как о некоем фасаде между сущностью и прикладной логикой, а внутри репозитория думаю найдется место и Criteria

mad_nazgul Jan 8 2019 at 07:40

Мне в большинстве случаев хватало native query.
Из-за этого кончено репозиторий становился сильнее привязан к конкретной БД.
Зато не надо ломать голову с Criteria API. Более не удобного способа работы с БД я еще не встречал :-)

arylkov Jan 8 2019 at 08:12

В Criteria был сделан упор на типизацию, на выявление ошибок еще на этапе компиляции, это видимо сделало его несколько сложным

mad_nazgul Jan 9 2019 at 08:21

ИМХО просто «странно» спроектированная «фигня».
Как минимум в PostgreSQL начиная с 8 версии типизация строгая.
Помню, когда переходил с 7-ой на 8-ю это доставило некоторое количество WTF-моментов

ris58h Jan 8 2019 at 12:03

Каким образом native query помогает решить проблему «динамических запросов с несколькими параметрами»?

mad_nazgul Jan 9 2019 at 08:28

Тем, что не надо писать динамические запросы с несколькими параметрами. ;-)
Точнее, можно оформить в виде репозитария несколько запросов с разными параметрами, собрав их из нескольких SQL-кусков.

Throwable Jan 8 2019 at 18:43

Все это хорошо пока не дойдешь до динамических запросов с несколькими параметрами

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

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

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

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

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

zesetup Jan 8 2019 at 23:08

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

mad_nazgul Jan 9 2019 at 08:33

Ничего не мешает. :-)
Пишешь native query и получаешь удобство декларативного SQL.