Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 14 15 [16] 17 18   вперед  Ctrl
 Re: Нужен ли нам ORM?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 515
Leonid Kudryavtsev

Как мы дошли до того, что в 2020-ых годах нужно "педалить" какой-то CRUD?

Почему в 90-ые даже слов таких не было.
Команда browse в FoxPro была, а вот и CRUD и даже потребности в оном - вот нифига не было ((( Вот что печалит (((

там не было транзакций, а crud как раз там был. там надо было, что типа use таблица и команды на уровне записи на птичем их языке.
а чего печального ? старперы фокспро даже спустя 30 лет не врубались что транзакция в фокспро - дурилово, мне помню пришлось даже тест им нарисовать что бы продемонстрировать, что commit реально не работает. современные джуны просто next level на фоне фокспро гайз с опытом.
30 апр 21, 12:10    [22316815]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
crutchmaster
Руками берешь и делаешь. Мухи Запросы в бд отдельно, классы с ООПотой отдельно. По сути ты делаешь почти тоже самое, что делает орм, только имеешь контроль над написанием запросом и тем, как результат будет мапиться на твои классы. Да, можно говорить "зачем велик, когда есть супер-пупер ОРМ на все случаи жизни", но орм иногда сосёт. Такие дела.
Ну вот я в сааамом первом посте описал почему это проблематично:
Stanislav Bashkyrtsev
Dirty checks
Если предыдущие проблемы можно хоть как-то решить через пень-колоду самому написав небольшие велосипеды, то dirty checks не понятно как преодолеть. Ну, не помещая при этом всю логику в сервисы конечно. Вызвав какой-то метод доменной модели мы можем поменять очень много полей и их не вернуть return у этого метода. Какие-то объекты удалятся, какие-то добавятся. Я не знаю как эту проблему можно красиво решить без ORM.
30 апр 21, 13:02    [22316846]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
booby

Она не только отгораживает тебя от того, в чем ты начинать разбираться не планируешь,
а, главное, снабжает верой в возможность замены того компонента, который находится за забором ОРМ.


Пока дело касается элементарных CRUD операций - да.
Но как только нужно что-то чуть сложнее.
То нужно знать не только как работает БД, но и как работает Hibernate с конкретной БД.

При это написать запрос на SQL оказывается гораздо проще, чем на HPQL, не говоря уже об CriteriaAPI.

При этом конкретная реализация работы с БД на Hibernate оказывается прибита гвоздями к конкретной СУРБД.

Например та же миграция с Oracle на PostgreSQL, приложения написанного с помощью Hibernate, даст много увлекательных приключений.
Помимо тех приключений, которые будут просто при миграции с Oracle на PostgreSQL.
30 апр 21, 14:20    [22316908]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
Leonid Kudryavtsev
mayton

...а педалить CRUD можно джунам на ORM.

Как мы дошли до того, что в 2020-ых годах нужно "педалить" какой-то CRUD?

Почему в 90-ые даже слов таких не было.
Команда browse в FoxPro была, а вот и CRUD и даже потребности в оном - вот нифига не было ((( Вот что печалит (((


Потому что при работе с FoxPro блокировалсь вся таблица.
Ну и ACID в FoxPro как такового не было.

Ну и FoxPro было СУРБД.
В принципе никто сейчас не мешает точно так же работать, например с Oracle или MS SQL.
30 апр 21, 14:26    [22316912]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Kachalov
Member

Откуда: Москва
Сообщений: 5817
mad_nazgul
Пока дело касается элементарных CRUD операций - да.
Но как только нужно что-то чуть сложнее.

- ну как только что-то "чуть сложнее", никто не помешает Вам использовать native SQL в запросе и Spring Data JPA Projections для маппинга на DTO. Или, как я уже предлагал, использовать DB First ORM - Apache Cayenne.

В целом проблема кажется надуманной, так как необходимые инструменты для работы со сложными запросами в рамках ORM существуют
30 апр 21, 14:53    [22316935]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
booby
Member

Откуда:
Сообщений: 2534
mad_nazgul
...
Потому что при работе с FoxPro блокировалсь вся таблица.
Ну и ACID в FoxPro как такового не было.

Ну и FoxPro было СУРБД.
В принципе никто сейчас не мешает точно так же работать, например с Oracle или MS SQL.


FoxPro - это вариант 4GL - то есть, программирование без программистов.
Вот был там Browse - и ешь его, как он есть.
Это не забор даже, а бетонная стена, что происходит за которой - не твое дело.
А, сейчас, ну вот жажду я такую стену, и не программист. Чему я должен на веб-странице сказать Browse одним словом,
чтобы из коробки за-use-анная таблица мигом отобразилась с красивыми заголовками, да еще и в режиме построчного редактирования?

А так-то ОРМ - он такой же, как SQL, только гораздо лучше.
Такой же в том смысле, что со сложной сторонней библиотекой заставляет общаться не методом изучения сложного процедурного АПИ,
а позволяет управлять ... кхм ... конфигурацией ... методом декларативной расстановки кракозябриков аннотаций.
Ведь проще заучить места расстановки аннотаций, и улётные эффекты от смены их местоположения, чем разбираться со всеми хитросплетениями SQL.
И, тем более, когда усилиями Фаулера модели толстых "бизнес-объектов" стали прокляты, и всех не просто обрекли на анемичные модели, а, натурально, еще и заставили радоваться этому.
Не имеет существенного значения, как именно там пройдет Dirty Check в зависимости от местоположения аннотации,
в условиях, когда почти с гарантией, независимо от их расстановки, в базу будет отправлен один и тот же update на все поля "сущности".

Сообщение было отредактировано: 30 апр 21, 15:10
30 апр 21, 15:18    [22316948]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
Kachalov
- ну как только что-то "чуть сложнее", никто не помешает Вам использовать native SQL в запросе и Spring Data JPA Projections для маппинга на DTO. Или, как я уже предлагал, использовать DB First ORM - Apache Cayenne.


Я так и делаю.
Пока хватает Spring Data Jpa - пофиг на ORM.
Как только начинается дичь.
Пишу ручками SQL-запросы.

Kachalov

В целом проблема кажется надуманной, так как необходимые инструменты для работы со сложными запросами в рамках ORM существуют


Скажем так. В основном ORM решает проблемы, которые сам же и создал. :-)
30 апр 21, 15:19    [22316949]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5687
booby
mad_nazgul
...
Потому что при работе с FoxPro блокировалсь вся таблица.
Ну и ACID в FoxPro как такового не было.

Ну и FoxPro было СУРБД.
В принципе никто сейчас не мешает точно так же работать, например с Oracle или MS SQL.


FoxPro - это вариант 4GL - то есть, программирование без программистов.
Вот был там Browse - и ешь его, как он есть.
Это не забор даже, а бетонная стена, что происходит за которой - не твое дело.
А, сейчас, ну вот жажду я такую стену, и не программист. Чему я должен на веб-странице сказать Browse одним словом,
чтобы из коробки за-use-анная таблица мигом отобразилась с красивыми заголовками, да еще и в режиме построчного редактирования?


Чта?!

FoxPro это наследник DBase.
Там программировать нужно было много и вкусно.
Правда элементы SQL немного облегчали жизнь.

Если говорить про "программирование без программистов", то это Clarion

booby

А так-то ОРМ - он такой же, как SQL, только гораздо лучше.


Хуже, гораздо хуже.

SQL - это декларативный ЯП.
ORM это попытка эмулировать декларативного ЯП в императивном ЯП.
Плохая попытка.
Т.к. декларативность ну очень сильно ограничена.
Просто сравнение возможностей HPQL/JPQL и SQL (даже если брать, какой-нибудь SQL99) идет не в пользу ORM.
А уж CriteriaAPI - это вообще хтонический ужас.
Для C# есть Linq - но опять же по сравнению с SQL возможности сильно ограничены.

Вообще идея ORM - это протекшая абстракция на стадии концепта.
30 апр 21, 16:05    [22316986]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
booby
Member

Откуда:
Сообщений: 2534
mad_nazgul

...
FoxPro это наследник DBase.
...

И что? Clipper - тоже наследник Dbase. И все они вместе - настоящие 4GL, без придури и прищура.

4GL как реализованная идея стартовал в 1967 году с https://en.wikipedia.org/wiki/MARK_IV_(software)
К 1982-му и 1985-му годам Джеймс Мартин в книжках запротоколировал, как программировать без программистов в языках 4го поколения.
https://en.wikipedia.org/wiki/James_Martin_(author)

mad_nazgul

SQL - это декларативный ЯП.
ORM это попытка эмулировать декларативного ЯП в императивном ЯП.
...

Я бы так это дело сформулировал - мне кажется, что любой вариант декларативного языка между плохо и никак,
стыкуется с императивным.
Одна из существенных проблем - генерализация интерфейсов с целью повторного использования вообще, и пограничных в частности,
на стороне декларативных языков. Декларативность почти автоматически синонимична скриптованию.
То есть, решению проблемы или задачи по месту. Это по задумке не соотносится с "проектированием больших систем".
Оно должно отвечать на тот вопрос, который внезапно примерещился вот этому конкретному пользователю.

Привнесение вообще аннотаций в спецификацию языка изначально произвело на меня шокирующее впечатление - это не программирование.
Со временем я стал много спокойнее. Вот был же 4GL для непрограммистов.
Это живая тема. Рано или поздно, каждый имеет право в рамках своего языка стать непрограммистом.
30 апр 21, 16:32    [22316993]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
fixxer
Member

Откуда:
Сообщений: 834
Stanislav Bashkyrtsev
Dirty checks
Если предыдущие проблемы можно хоть как-то решить через пень-колоду самому написав небольшие велосипеды, то dirty checks не понятно как преодолеть. Ну, не помещая при этом всю логику в сервисы конечно. Вызвав какой-то метод доменной модели мы можем поменять очень много полей и их не вернуть return у этого метода. Какие-то объекты удалятся, какие-то добавятся. Я не знаю как эту проблему можно красиво решить без ORM.


Ну вот также и решать. Руками. Проектируя репозитории с явным методом save, который вызываете в Application Service после вызова бизнес-метода на агрегате. И не нужно логику в сервис выносить. А по-поводу того, что что-то там много удаляется/добавляется, может вы поленились спроектировать точечные агрегаты под юзкейсы и пользуетесь одним толстым на все случаи жизни? Вообще, наличие в модели @OneToMany части ассоциации и работа "через коллекцию" зачастую уже попахивает. Всегда можно перепроектировать так, чтобы работать со стороны Many, а в случае отсутствия ОРМ это уже необходимость. Вообще, я бы посмотрел на пример, который вызывает затруднение, возможно там есть ошибка в проектировании доменной модели.
30 апр 21, 17:06    [22317012]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
booby
До тех пор, пока ты не просто знать не хочешь, а на голубом глазу, честно, представления не имеешь, как там, что и зачем -
ОРМ страшно полезная и страстно необходимая штука.
Она не только отгораживает тебя от того, в чем ты начинать разбираться не планируешь,
а, главное, снабжает верой в возможность замены того компонента, который находится за забором ОРМ
хорошо сказано.
Leonid Kudryavtsev
Зачем изучать СУБД - если можно взять Hibernate
и это хорошо подмечено.
mayton
. И я готов спорить на виски что инструктор не читает
Java-истам курс SQL. А раз не читает то у них нет знаний (даже самых элементарных) как использовать SQL.
И нет у них никакой мотивации на производстве изучать SQL. Зачем? Им - некогда. Им надо быстро закрыть
таску и взять следующую. И это также проблема тех-лидов которые тоже успели перепрыгнуть через это знание.
Или они этим знанием по "фарисейски" обладают но не делятся. Полагая что синьорные задачи они сами решат
а педалить CRUD можно джунам на ORM.
и тут золотые слова.
а вот когда займешься использованием самописных запросов, и входишь во вкус, начинаешь понимать, что можно ещё и ещё увеличивать прогресс. и пробуешь хранимые процедуры. и тут уже осознаёшь всю мощь sql.
единственно надо выкинут из головы - термин бизнес логика в бд. нет там никакой "бизнес логики" - там просто обработка данных. ради интереса почитайте что могут хранимые процедуры в mssql. это мощнейший инструмент.
версионность, сопровождение - это всё отмазки.
30 апр 21, 18:21    [22317040]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
fixxer
Stanislav Bashkyrtsev
Dirty checks
Если предыдущие проблемы можно хоть как-то решить через пень-колоду самому написав небольшие велосипеды, то dirty checks не понятно как преодолеть. Ну, не помещая при этом всю логику в сервисы конечно. Вызвав какой-то метод доменной модели мы можем поменять очень много полей и их не вернуть return у этого метода. Какие-то объекты удалятся, какие-то добавятся. Я не знаю как эту проблему можно красиво решить без ORM.


Ну вот также и решать. Руками. Проектируя репозитории с явным методом save, который вызываете в Application Service после вызова бизнес-метода на агрегате. И не нужно логику в сервис выносить.
Возьмем какой-нить простенький пример.. Есть у нас:
class Person {
  Person psychiatrist;
  ShoppingList shoppingList;

  void kill() {
     this.psychiatrist = psychiatrist;
     this.shoppingList = null;
  }
}
Т.е. если мы убиваем человека, то:
1. Психиатр ему больше не нужен, мы хотим эту связь порвать
2. В магазин он тоже больше не пойдет - ShoppingList ему не нужен. При том что ShoppingList в таком случае мы вообще хотели бы из БД удалить.

Создать какой-то обобщенный метод repository.save(person) не получится, потому как он не будет знать какие же поля обновлять, и что ShoppingList нужно удалить. Как в таком случае правильно поступить без ORM'a?
fixxer
А по-поводу того, что что-то там много удаляется/добавляется, может вы поленились спроектировать точечные агрегаты под юзкейсы и пользуетесь одним толстым на все случаи жизни?
Так и есть. Но даже если я "не поленюсь" и создам точечные агрегаты, у меня много случаев в приложении когда какое-то действие от пользователя провоцирует целый каскад изменений. Т.е. даже точечному агрегату может потребоваться как-то трекать удаление/обновление/создание сотен объектов.

Но даже с супер-точечным агрегатом я не понял как эту проблему решать. Жду пояснений по 1ому пункту.
fixxer
Вообще, наличие в модели @OneToMany части ассоциации и работа "через коллекцию" зачастую уже попахивает. Всегда можно перепроектировать так, чтобы работать со стороны Many, а в случае отсутствия ОРМ это уже необходимость.
Хм.. я на это смотрел как техническую проблему. Мол, да, OTM будет работать медленней из-за того как Hibernate работает с коллекциями (это конечно решается bidirectional связью, но она попахивает еще больше). Но я не смотрел на это как на проблему самой модели. Чем это плохо?
fixxer
Вообще, я бы посмотрел на пример, который вызывает затруднение, возможно там есть ошибка в проектированиих доменной модели.
Ох, я бы очень хотел это кому-то показать, послушать советы. Но предметная область оч сложная (АРМ для химиков, с роботизацией и пр), по опыту люди в это начинают въезжать не быстрей чем за полгода :( Ну не говоря уже про NDA.

Сообщение было отредактировано: 30 апр 21, 18:15
30 апр 21, 18:21    [22317041]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9651
Stanislav Bashkyrtsev

Возьмем какой-нить простенький пример.. Есть у нас
...
Т.е. если мы убиваем человека, то:

Вот ровно мой пример с подсчетом кол-ва яблок у Васи и Пети через стримы

DELETE person WHERE id = :id;

если кто-то (так делать конечно не нужно), сделал каскадные констрейны (imho зло), то все остальное даже само удалится.
30 апр 21, 18:33    [22317044]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
Stanislav Bashkyrtsev,

была одна система, был в ней один фрагмент -изделие - рулон спец упаковки. для него аттестации проводилась куча опытов. и всё хранилось в базе. элементарно вписывалось в ООП - рулон - объект, каждый опыт - ещё объект со своими параметрам.
вопрос - а нафига эти объекты? всё элементарно ложилось в crud. измерил занёс - табличку.
и можно считать, что набор записей в таблицах - это и есть "объект" .
можно вытащить "весь объект" и отобразить юзеру , можно изменить любое поле этого "объекта" прямо в таблице. и нафига для этого держать эти "объекты" (их несколько в партии) в памяти?
даже при лимонах таких изделий обращении к бд - минимум нагрузки на бд.
30 апр 21, 18:36    [22317045]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
booby
Member

Откуда:
Сообщений: 2534
Stanislav Bashkyrtsev

...
Т.е. если мы убиваем человека, то:
1. Психиатр ему больше не нужен, мы хотим эту связь порвать
2. В магазин он тоже больше не пойдет - ShoppingList ему не нужен. При том что ShoppingList в таком случае мы вообще хотели бы из БД удалить.
...


С логической точки зрения, способ действия зависит от цели.
Если цель состоит в сожжении всех связанных с этим человеком артефактов, так, чтобы и памяти о нём не осталось,
то на стороне базы данных это поддерживается каскадным удалением связанных внешними ключами дочерних записей или очисткой значений внешних ключей.
орм-у достаточно убить самого человека, а база данных автоматических выжжет из дисковой памяти все связанные с ним артефакты.

Если же планируется хотя бы могилку для убиенного оставить, то он не удаляется, а помечается ... как worked out, например.
30 апр 21, 18:38    [22317047]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
Stanislav Bashkyrtsev
Ох, я бы очень хотел это кому-то показать, послушать советы.
а я б не против посмотреть насколько это можно изменить в проекции на бд
хотя может оказаться это один и тех вариантов, что не имеет даже теоретической возможности ...
только вот тогда плохо , что ты этот проект распространяешь на всё остальное.
30 апр 21, 18:43    [22317049]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
booby
Member

Откуда:
Сообщений: 2534
Leonid Kudryavtsev
...
DELETE person WHERE id = :id;
если кто-то (так делать конечно не нужно), сделал каскадные констрейны (imho зло), то все остальное даже само удалится.

А если кто-то сделает не каскадные констрейнты, то этот delete пришлет ошибку времени выполнения, с рассказом о том, что нельзя удалять строку, для которой существуют связанные с ней артефакты в других таблицах.

Именно поэтому - только железобетонный ОРМ, и с не просто с запретом на хранимые процедуры в базе,
а с кровавым запретом на существование констрейнтов в ней.
Кому же охота получать от базы "не буду удалять", если ей приказано было удалить...

Сообщение было отредактировано: 30 апр 21, 18:47
30 апр 21, 18:55    [22317054]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
Вроде это было очевидно из кода, но скажу все-таки явно: убитый пользователь конечно же остается в базе. У него будет какое-то поле isDead=true.

Ну и проблема конечно же не написать SQL запрос, а определить для каких сущностей его вообще писать (e.g. какие ID передавать в where).

Сообщение было отредактировано: 30 апр 21, 19:22
30 апр 21, 19:22    [22317063]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18692
Stanislav Bashkyrtsev,

сначала создадим проблему, потом будем решать....
при правильной постановки тз этих проблем не бывает
30 апр 21, 19:46    [22317071]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
fixxer
Member

Откуда:
Сообщений: 834
Stanislav Bashkyrtsev,
this.psychiatrist = psychiatrist;

Мне вот этот пассаж не совсем понятен, можете пояснить?

автор
class Person {
  Person psychiatrist;
  ShoppingList shoppingList;
  // ...
}



1. Очевидно, что такой Person в грамотной доменной модели не может появиться. Тут налицо смешение трех Bounded Context (ну скажем, People, Patients, Shopping) в одном классе.

2. Person будет помечен мертвым, после чего возникнет доменное событие PersonReportedDead, при обработке которого удалятся Patient и ShoppingList в соответствующих контекстах.

Хм.. я на это смотрел как техническую проблему. Мол, да, OTM будет работать медленней из-за того как Hibernate работает с коллекциями (это конечно решается bidirectional связью, но она попахивает еще больше). Но я не смотрел на это как на проблему самой модели. Чем это плохо?

Вот теми техническими проблемами и плохо, провоцирует либо n+1, либо загрузку лишнего. Лучше пользоваться другой стороной @ManyToOne. Ну а в случае отсутствия ОРМа, там вообще просто id будет, а не материализованная связь.

Сообщение было отредактировано: 30 апр 21, 19:55
30 апр 21, 20:02    [22317074]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
fixxer
Stanislav Bashkyrtsev,
this.psychiatrist = psychiatrist;

Мне вот этот пассаж не совсем понятен, можете пояснить?
Тьху, сорян. Там должно быть:
this.psychiatrist = null;


fixxer
1. Очевидно, что такой Person в грамотной доменной модели не может появиться. Тут налицо смешение трех Bounded Context (ну скажем, People, Patients, Shopping) в одном классе.
Это придирка к тому что выдуманная модель недостаточно реалистична? Ну в целом ты же можешь себе представить ситуацию когда у нас есть класс А, в нем ссылки на два класса Б и В?
fixxer
2. Person будет помечен мертвым, после чего возникнет доменное событие PersonReportedDead, при обработке которого удалятся Patient и ShoppingList в соответствующих контекстах.
Сколько бы ни было контекстов, это все внутри Агрегатов и Entities? Если так, то проблема остается прежней: как Repository узнает об изменении внутри Entity?
Кстати, кто слушатель этих событий?
fixxer
Stanislav Bashkyrtsev
Хм.. я на это смотрел как техническую проблему. Мол, да, OTM будет работать медленней из-за того как Hibernate работает с коллекциями (это конечно решается bidirectional связью, но она попахивает еще больше). Но я не смотрел на это как на проблему самой модели. Чем это плохо?
Вот теми техническими проблемами и плохо, провоцирует либо n+1, либо загрузку лишнего. Лучше пользоваться другой стороной @ManyToOne. Ну а в случае отсутствия ОРМа, там вообще просто id будет, а не материализованная связь.
Нет, n+1 тут не возникает, мы всю коллекцию можем выгрузить одним запросом. А если и возникает (каждый элемент коллекции ссылается еще на коллекцию), то значит и во время загрузки этих элементов вне коллекции (их все равно нужно загрузить N как ни крути) проблема будет та же.

OTM проблемный по другой причине - ему нужно два запроса на сохранение элементов:
1. Сначала INSERT самих элементов (без сохраненной связи, и привет not-null constraint кстати)
2. А затем отдельным UPDATE будет проставляться FK

Поэтому при использовании ORM мы стараемся либо использовать MTO, либо bidirectional связь. Но это чтоб достичь лучшей производительности, а не потому что "модель так лучше".
30 апр 21, 21:19    [22317087]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
booby
Member

Откуда:
Сообщений: 2534
Stanislav Bashkyrtsev,
попробую свой вариант перевода на русский того, о чем пытается сказать fixxer.

Прежде всего, связи связям рознь.
Они могут быть вечно неизменными, сохраняемыми временными (т.е. у них есть время начала и завершения действия)
или сессионными временными, существующими не дольше, чем время видимости объекта в использующем объект коде.

В этом вашем "примере" Person, чем бы он ни был на самом деле, скорее всего не "персистентный".

Вот психиатрист, например. Что может заставить вязать психиатриста напрямую к персистентному персону в нём самом?
Даже мёртвый персон, пока жил, мог консультироваться у нескольких психиатристов, как в разные периоды жизни, так и одновременно.
Ок. Пусть он не персон, а конкретный визит к психиатристу, и мы дело имеем не с записями о персоне и его связях с психиатристами,
а с конкретным бизнес-процессом, поддерживающим визит персона к конкретному психиатристу,
в процессе которого оказывается для вынесения диагноза востребован список покупок, совершенных во время последнего посещения ближайшего торгового сарая.

Допустим, что по любой причине, сам список становится не интересен по вынесению диагноза и подлежит удалению.
Тогда для поддержки живущего только во время процесса вынесения диагноза списка (сессионно), может использоваться нечто,
со стороны бд называемое "временной таблицей".
Если та такое поддерживает, то со стороны ОРМ не требуется совсем никаких специальных действий по удалению временной информации по завершению сеанса. Иначе требуется, но это будет взгляд именно со стороны "many", то есть - самого списка.

В языках с деструкторами приказ на удаление отдался бы просто в деструкторе объекта.
В противном случае понадобится метод сорта "завершить сеанс".

Сообщение было отредактировано: 30 апр 21, 22:16
30 апр 21, 22:23    [22317095]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
fixxer
Member

Откуда:
Сообщений: 834
Stanislav Bashkyrtsev


fixxer
1. Очевидно, что такой Person в грамотной доменной модели не может появиться. Тут налицо смешение трех Bounded Context (ну скажем, People, Patients, Shopping) в одном классе.
Это придирка к тому что выдуманная модель недостаточно реалистична? Ну в целом ты же можешь себе представить ситуацию когда у нас есть класс А, в нем ссылки на два класса Б и В?

С таким жизненным циклом? С трудом представляю. Приведите пример, когда связь явно принадлежит одному контексту. Я к тому, что пример с удалением кажется мне искусственным. Этого можно избежать проектируя модель по-другому, когда без ОРМ просто будет срабатывать каскадное удаление, либо через те же доменные события.

Stanislav Bashkyrtsev

fixxer
2. Person будет помечен мертвым, после чего возникнет доменное событие PersonReportedDead, при обработке которого удалятся Patient и ShoppingList в соответствующих контекстах.
Сколько бы ни было контекстов, это все внутри Агрегатов и Entities? Если так, то проблема остается прежней: как Repository узнает об изменении внутри Entity?
Кстати, кто слушатель этих событий?

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

Stanislav Bashkyrtsev

OTM проблемный по другой причине - ему нужно два запроса на сохранение элементов:
1. Сначала INSERT самих элементов (без сохраненной связи, и привет not-null constraint кстати)
2. А затем отдельным UPDATE будет проставляться FK

Спасибо, я упустил данный момент.

Stanislav Bashkyrtsev

Поэтому при использовании ORM мы стараемся либо использовать MTO, либо bidirectional связь. Но это чтоб достичь лучшей производительности, а не потому что "модель так лучше".


Ну так мы не можем проектировать модель в отрыве от ее применения. Это идеализм какой-то ненужный. Поэтому модель поощряющая более производительное ее применение будет лучше.
30 апр 21, 22:49    [22317100]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
asv79
Member

Откуда: Тверь
Сообщений: 3319
mad_nazgul
booby

Она не только отгораживает тебя от того, в чем ты начинать разбираться не планируешь,
а, главное, снабжает верой в возможность замены того компонента, который находится за забором ОРМ.


Пока дело касается элементарных CRUD операций - да.
Но как только нужно что-то чуть сложнее.
То нужно знать не только как работает БД, но и как работает Hibernate с конкретной БД.

При это написать запрос на SQL оказывается гораздо проще, чем на HPQL, не говоря уже об CriteriaAPI.

При этом конкретная реализация работы с БД на Hibernate оказывается прибита гвоздями к конкретной СУРБД.

Например та же миграция с Oracle на PostgreSQL, приложения написанного с помощью Hibernate, даст много увлекательных приключений.
Помимо тех приключений, которые будут просто при миграции с Oracle на PostgreSQL.

ерунду ты пишешь полную .Хибер нужно для начала изучить,а если ваши познания заканичиваюся CRUD операциями - то причем тут Hibernate
1 май 21, 00:21    [22317118]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
fixxer
Stanislav Bashkyrtsev

пропущено...
Сколько бы ни было контекстов, это все внутри Агрегатов и Entities? Если так, то проблема остается прежней: как Repository узнает об изменении внутри Entity?
Кстати, кто слушатель этих событий?

Агрегаты и сущности живут внутри контекстов, не наоборот. (Давайте вы освежите DDD у тех же Эванса и Вернона, чтобы нам об одном и том же говорить) А так как, в данном случае, события пересекают границы контекстов, то слушатели это сервисы, которые в свою очередь поднимут репозиториями агрегаты соответствующего контекста и применят изменения, диктуемые событием.
Я к тому что даже с событиями о которых ты говоришь - кто-то что-то вызовет у Агрегатов, те что-то вызовут у Entities. Изменения произойдут внутри этих объектов. Да и не надо вообще выходить за пределы Bounded Context. У нас всего один он. И у меня вполне конкретный вопрос: как об изменениях внутри Entities (а они обязательно будут) узнает Repository?

Я вот счас пролистал Еванса и не нашел там упоминаний Доменных Событий. Что ты под этим подразумеваешь? Как это выглядит?
fixxer
Stanislav Bashkyrtsev

Поэтому при использовании ORM мы стараемся либо использовать MTO, либо bidirectional связь. Но это чтоб достичь лучшей производительности, а не потому что "модель так лучше".
Ну так мы не можем проектировать модель в отрыве от ее применения. Это идеализм какой-то ненужный. Поэтому модель поощряющая более производительное ее применение будет лучше.
Как и в brainstorm'ах, сначала мы придумываем модель как будто никаких ограничений не существует. А потом мы задумываемся над ограничениями и начинаем переделывать "идеальные" концепции под реалии жизни. Разные хранилища будут налагать разные ограничения. И то, что OTM - дорого с точки зрения ORM, это еще не значит что мы должны вовсе от них отказываться. Возможно это ухудшает производительность совсем незаметно, а улучшает дизайн очень заметно. Или это ухудшает дизайн настолько сильно, что мы откажемся от ORM в данном случае. Это все вопросы которые решаются после. А то если мы просто откажемся от всех коллекций в Entities, то получим какой-то неуклюжий обрубок модели..

Сообщение было отредактировано: 1 май 21, 09:43
1 май 21, 09:49    [22317153]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 14 15 [16] 17 18   вперед  Ctrl
Все форумы / Java Ответить