Привет!

Конкурирущая фирма пиарит JPA

Но автор почему-то среди альтернатив потерял Spring Data JDBC, который обладает практически всеми перечисленными достоинствами, кроме кэша (который не особо нужен нормальным приложениям), мультитенантности (вот тут да, будет боль) и генерации схемы.

И при этом забыл пару фатальных недостатков - противоречие классическим принципам дизайна и программирования и кое-что новенькое для этого чатика

Существует принцип проектирования API под названием "Pit of Success (Яма успеха)" - суть в том, чтобы разработчики "плывущие по течению" делали правильные вещи. В случае же JPA "разработчики плывущие по течению" будут создавать приложения с плохим дизайном (все сущности связаны двунаправленными связями) и производительностью (кучи N+1 запросов).

#posts@ergonomic_code #jpa@ergonomic_code

Привет!

Мне вчера JPA на пару со Spring подложили очередную свинью.
Хотел показать студентам LazyInitializationException и не смог О_О
Забацал типовой пример - транзакционный сервис возвращает сущность с ленивым полем в контроллер, контроллер его достаёт для ДТО и должен был упасть, но, собака, уверено работал.

Полчаса позора спустя я откопал вот такой нежданчик. Который несёт свой собственный набор граблей. Специалисты по JPA, наверное, о нём в курсе, но вдруг тут есть кто-то ещё из танка, как и я.

#spring@ergonomic_code #jpa@ergonomic_code

Привет!

Пара баек про JPA. Для молодых разработчиков, в первую очередь.

Мне тут недавно студент сдавал в качестве курсового проекта стартап с живым клиентом в проде. И между делом рассказал душещипательную историю в духе "У нас основное приложение на JPA, но в первый же день в проде оно нам покасячило данные, поэтому админку мы начали делать на jooq, чтобы лучше контролировать работу с БД".

А вчера говорил наоборот с пишущим код СТО c опытом работы с JPA лет 10 минимум и между делом я написал "в какой-то момент мне показалось, что я с JPA освоился и закончу активную разработку на этой недели".

На что получил ответ:

> Ахахаха
это классика
я после задач с JPA никогда не говорю теперь что с ним освоился/разобрался
я его б*ь не знаю, там вечные сюрпризы и темные пятна вылазят

В общем прежде чем брать в проект JPA советую сначала попробовать затолкать в голову собственно саму 662-страничную Jakarta Persistence API Specification :) Перед тем как ещё страниц ~100 рефернсной доки на Spring Data JPA читать. И я уж молчу про 228 страниц спеки на JDBC. Жаль, спека на SQL непубличная - говорят в свежих версиях там 1000 страниц. Кто-нибудь, остановите меня уже:)

#whynotjpa@ergonomic_code #jpa@ergonomic_code

Привет!

Я посмотрел Migrating from (Spring Data) JPA to Spring Data JDBC.
И пересмотрел Меняем Spring Data JPA на Spring Data JDBC! (на который уже писал своё фи).

Удивительно, насколько эти доклады об одном и том же разные:
1. Дженс начинает с тестов и выделяет для них целый слайд. Андрей между делом упоминает их в конце доклада
2. Дженс топит за то, чтобы делать это очень аккуратно и постепенно и рассказывает про любопытную методику больших рефакторингов. А Андрей шарашит с распахнутым забралом и даже без тестов
3. Дженс практически ~50% доклада (~20 минут из ~40) посвящает перепроектированию модели данных. Андрей посвящает этому ~3% (~2 минуты из ~60)
4. Естественно, Дженс чморит JPA, а Андей - SDJ

Зато, оба доклада раскрывают тему генерации id 🤷‍♂️ И я до сих пор не понимаю, чем default nextval('seq') плох, раз уж generated always as identity не подходит

И эта разница навела меня на новый аргумент против jpa за sdj.

При разработке приложения на базе JPA основными сложностями будут изучить саму JPA, потом накастовать аннотаций, чтобы она делала то, что надо, а через полгода угадывать как это всё будет работать. Это всё - привнесённая сложность (Accidental complexity), которую можно и не привносить.

А при разработке приложения на базе SDJ основной сложностью будет декомпозиция модели на агрегаты. И вот это уже сложность, присущая задаче.

И хотя, теоретически, JPA позволяет так же выполнить декомпозицию модели, она не обязывает это делать.
В результате в приложениях на JPA на декомпозицию предметной области забивают и в ответ получают Big Ball of Mud. Так произошло в 100% проектах на JPA, которые я видел.

Проектирование агрегатов - действительно сложная тема и по ней написано много хороших книг. Но с ними со всеми есть одна проблема - они полагаются на экспертов предметной области.

И хотя это лучший способ выполнить декомпозицию предметной области, у него есть недостатки:
1. Эксперты предметной области зачастую недоступны в принципе.
2. А когда доступны - извлечение формальной модели из головы другого человека средствами естественного (неформализованного) языка - это в целом задача на уровне "мишшн импоссбл", а для многих технических специалистов просто за гранью понимания.

Из-за этого проектирование агрегатов зачастую хромает на обе ноги.

Поэтому я сейчас использую более технический подход к проектированию агрегатов. Об этом подходе надо написать отдельный пост, но если вкратце, он выглядит так:
1. Спроектировать ЕР модель, особое внимание уделить слабым сущностям
1.1 Признаки слабой сущности:
1.1.1 её жизненный цикл ограничен жизненным циклом другой сущности - позиция заказа не может существовать без заказа, номер не может существовать без отеля
1.1.2 она упоминается всегда в контексте другой сущности - вторая строчка заказа такого-то, номер 215 отеля такого-то
2. Все стержневые сущности (со слабыми и без них) считаются корнями агрегатов
3. Провести транзакционный анализ - в идеале в рамках одной транзакции должен меняться один агрегат и меняться целиком. Если это не так - что-то надо объединить, а что-то разделить.

Этот подход базируется на косвенных признаках (жизненный цикл сущностей и UI), поэтому он, скорее всего, даст менее точную модель, чем построение модели вместе с экспертом. Но он не требует эксперта и общения с ним. И лучше так, чем никак.

Ещё ссылки по теме:
1. Нотация описания неизменяемой модели данных (+ Ответы на вопросы по Эргономичной нотации ER-модели)
2. Агрегаты
3. Рациональный подход к декомпозиции систем на модули или микросервисы

В общем, инвестируйте свой интеллект в решение присущей сложности задачи, а не привнесённой:)

#why_sdj@ergonomic_code #whynojpa@ergonomic_code #ddd@ergonomic_code #spring_data_jdbc@ergonomic_code #jpa@ergonomic_code