arylkov 7 янв 2019 в 06:37

Spring Data JPA

9 мин

304K

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

zesetup 7 янв 2019 в 11:15

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

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

arylkov 7 янв 2019 в 14:39

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

ruslanys 7 янв 2019 в 17:52

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

arylkov 7 янв 2019 в 18:01

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

mad_nazgul 8 янв 2019 в 04:40

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

arylkov 8 янв 2019 в 05:12

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

mad_nazgul 9 янв 2019 в 05:21

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

ris58h 8 янв 2019 в 09:03

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

mad_nazgul 9 янв 2019 в 05:28

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

Throwable 8 янв 2019 в 15:43

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

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

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

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

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

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

zesetup 8 янв 2019 в 20:08

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

mad_nazgul 9 янв 2019 в 05:33

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Spring Data JPA

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

Публикации

Истории