Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 18   вперед  Ctrl
 Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
По мотивам этой темы:

mad_nazgul
Hibernate решает сложные проблемы, которые сам себе в начале создал.
Из-за отображения ООМ на РМД.
Простые вещи он усложняет до невозможности.
Вместо, того, чтобы делать нормальный DTO ручками.
Приходиться скрещивать ужа с ежом, чтобы получить пони.
<:o)

Stanislav Bashkyrtsev
mad_nazgul
Hibernate решает сложные проблемы, которые сам себе в начале создал.

Сложные проблемы которые он решает и которые сам себе не создавал - это ленивая загрузка и поддержка больших графов объектов, dirty check'и, каскады, поддержание PersistenceContext'a и т.п.
mad_nazgul
Простые вещи он усложняет до невозможности.
Вместо, того, чтобы делать нормальный DTO ручками.
Приходиться скрещивать ужа с ежом, чтобы получить пони.
Простые штуки вроде вернуть DTO можно сделать как с Hibernate'ом:
- с помощью select new
- создание более удобных сущностей под задачу, которые мапятся на те же таблицы, но по-другому
- маппинг на вьюшки

Так можно решать их и без него, никто не мешает миксовать Hibernate и JDBC - это вполне себе подход. Простым проблемам - простой инструмент.

mad_nazgul
Да хибер притащил понятие ленивость.
Что значит ленивость?
Это когда вместо реального объекта посдтавляется прокси, при обращении к которому, делается запрос и подтягиваются данные.

Без ОРМ никакой "ленивой" загрузки не надо.
Запросом вытаскиваешь данные и раскладываешь по объектам.
22 апр 21, 18:04    [22312727]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
mad_nazgul, я не представляю как написать красивый ООП код по мотивам Rich Model без этих фичей ORM. Наверно можно, но я не представляю. Это конечно все нужно для сложный приложений с развесистой доменной моделью. Ведь чем меньше приложение, тем проще модель и меньше проблем с объектами и как их доставать из базы.

Графы объектов и ленивость
ORM позволяет нам:
1. Не писать по 20 разных методов в DAO слое по вытаскиванию разных вариантов одних и тех же объектов. В одном случае нужно одно поле, в другом - два поля и т.д.
2. Не думать о том что же будет если два разных объекта ссылаются на один и тот же. В случае JDBC нам нужно самим реализовывать PersistenceContext для того чтоб убедиться что они правда ссылаются на один и тот же объект, а не две копии этого объекта.

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

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

Откуда:
Сообщений: 3471
проблемы отпадут если убрать из постановки ООП и Rich Model. Не думаю что клиенты платят за это:)
22 апр 21, 18:21    [22312738]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник
проблемы отпадут если убрать из постановки ООП и Rich Model.
Да, эту тему имеет смысл обсуждать только с теми у кого есть желание использовать ООП. Если пишем процедурно, то ORM и правда не так много плюшек предоставляет. Они все равно есть, но стоят ли они того чтоб изучать такой сложный инструмент..

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

Откуда:
Сообщений: 8254
Stanislav Bashkyrtsev,
Желание мало. АппСервер тогда выкидывать. И трехзвенку.
22 апр 21, 18:33    [22312742]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

Откуда:
Сообщений: 3471
Stanislav Bashkyrtsev
забыл ник
проблемы отпадут если убрать из постановки ООП и Rich Model.
Да, эту тему имеет смысл обсуждать только с теми у кого есть желание использовать ООП. Если пишем процедурно, то ORM и правда не так много плюшек предоставляет. Они все равно есть, но стоят ли они того чтоб изучать такой сложный инструмент..

к сожалению или к счастья, но парадигм программирования больше чем количество вами осиленных, то бишь 2.
22 апр 21, 18:36    [22312744]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник
парадигм программирования больше чем количество вами осиленных, то бишь 2.
Не спорю. Я лишь говорю о том что ORM не имеет большого смысла обсуждать если не используешь ООП.
22 апр 21, 18:42    [22312746]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 8254
Stanislav Bashkyrtsev
забыл ник
парадигм программирования больше чем количество вами осиленных, то бишь 2.
Не спорю. Я лишь говорю о том что ORM не имеет большого смысла обсуждать если не используешь ООП.
вот и тупик))
Парадигмы всякие нужны, парадигмы всякие важны (с)
Не нужен только оператор goto)))))
22 апр 21, 19:29    [22312767]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
mayton
Member

Откуда: loopback
Сообщений: 51389
Stanislav Bashkyrtsev
mad_nazgul, я не представляю как написать красивый ООП код по мотивам Rich Model без этих фичей ORM. Наверно можно, но я не представляю. Это конечно все нужно для сложный приложений с развесистой доменной моделью. Ведь чем меньше приложение, тем проще модель и меньше проблем с объектами и как их доставать из базы.

А это ООП код?

try (Statement statement = connection.createStatement()) {
            logger.info("execute query : {}", query);
            statement.setFetchSize(jdbcFetchSize);
            statement.executeQuery(query);
            try(ResultSet resultSet = statement.getResultSet()) {
                int rows = 0;
                long batches = 0;
                while (true) {


автор
Графы объектов и ленивость

Вот с этого момента стоп.

Я кое-что понимаю в графах. По крайней мере использовал Neptune, Jena. И ты не поверишь, для полноценной
работы с графом достаточно было использовать SPARQL в качестве языка запросов. Опять-же термин "объект из ООП"
там не применялся.

В моём понимании граф появляется там где есть графовая БД и мы можем найти циклы в данных.

Или у тебя какие-то "другие" графы?
22 апр 21, 21:41    [22312809]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
hck2
Member

Откуда:
Сообщений: 54
я вот смотрю на spark и не понимаю почему он порвал всю аналитику, но так ничего схожего не пришло на замену орм. отличный же синтакис. data first идея, функциональщики должны быть от него просто в восторге, олд скульные товарищи привыкшие к SQL ну тоже вполне могли бы привыкнуть к .select().filter().join() для совсем уже упертых просто SQL строка можно.
все логично, все понятно, куски логики можно как параметры передавать. ну карсота же. я понимаю почему непосредственно спарк не заменил, но почему с spark идеей и синтаксисом не сделать аналог C# LINQ ?
глядя на нездоровую уже любовь к спарку в майкрософте на ниве аналитики, не удивлюсь если это первые майкрософт сделают в .net

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

Откуда: СПб
Сообщений: 137
mayton
А это ООП код?

try (Statement statement = connection.createStatement()) {
            logger.info("execute query : {}", query);
            statement.setFetchSize(jdbcFetchSize);
            statement.executeQuery(query);
            try(ResultSet resultSet = statement.getResultSet()) {
                int rows = 0;
                long batches = 0;
                while (true) {
Это не относящийся к данной дискуссии код.. Это просто API которое нам нужно использовать для получения данных из хранилища. Речь же о том как мы описываем нашу бизнес логику. Чаще всего в Java проектах логику описывают в сервисном слое реализуя то что Fowler называет Transaction Script'ом. Наши сущности (Entity) в такой схеме - это структуры данных по типу тех что есть в C. Такую модель называют Анемичной. Есть так же ООП подход который все тот же Fowler прозвал Domain Model aka Rich Model.
mayton
Я кое-что понимаю в графах. По крайней мере использовал Neptune, Jena.
Речь конечно же не про абстрактную структуру данных и не про графовые QL/базы :) А просто про взаимосвязанные объекты доменной модели сохраненные (в нашем случае) в виде таблиц реляционной БД.
22 апр 21, 22:12    [22312824]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

Откуда:
Сообщений: 3471
hck2
но почему с spark идеей и синтаксисом не сделать аналог C# LINQ ?

ну вообще Slick именно это и делает, но там есть свои нюансы. И даже термин для него свой придумали FRM(Functional Relational Mapping), только факт остается фактом - лучшего языка по доступу к данным в БД чем SQL не существует, когда запрос занимает три скрина, то никакие join.filter.select() не помогут, ибо нихера становится непонятно. А портянку SQL можно экстрактнуть в блокнот и посмотреть что там и как. Кстати и в spark мы тоже предпочитаем spark.sql() датафреймам
22 апр 21, 22:38    [22312836]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

Откуда:
Сообщений: 3471
Stanislav Bashkyrtsev
Есть так же ООП подход который все тот же Fowler прозвал Domain Model aka Rich Model.


Ну и много ли он привел примеров, реализованных проектов по этой схеме, которые можно скачать и запустить? Ну или вообще можно ссылочку на ЛЮБОЙ классический rich model пример?
Куда в такой модели кладется логика persistence, в какой богатый объект? А валидация? А куда отправить метод transfer(account a1, account a2)?
Так то конечно Файлур мастер языком и руками водить, и я даже признаю его заслуги по ситематизации паттернов в свое время, жаль только что ООП это dead-end и dark era of programming. К счастью темные века рано или поздно заканчиваются и ООП сгинет в пучине в ближайшее десятилетие, не считая саппорта древних проектов, на которые будут садить провинившихся джуниоров
22 апр 21, 22:50    [22312842]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
hck2
Member

Откуда:
Сообщений: 54
забыл ник

ну вообще Slick именно это и делает, но там есть свои нюансы. И даже термин для него свой придумали FRM(Functional Relational Mapping), только факт остается фактом - лучшего языка по доступу к данным в БД чем SQL не существует, когда запрос занимает три скрина, то никакие join.filter.select() не помогут, ибо нихера становится непонятно.

какая-то ерунда. в этом то и фишка, что в спарке все куски логики можно аккуратно разложить по классам и вообще передавать датасеты, лямды как параметры. нет требования нафигачить три этажа как у SQL.

забыл ник

А портянку SQL можно экстрактнуть в блокнот и посмотреть что там и как. Кстати и в spark мы тоже предпочитаем spark.sql() датафреймам

ну все таки написать тест и продебажить отдельные методы - много, много удобней, чем портянки в блокноте парсить умозрительно. а то что вы spark.sql() юзаете, так вы же большую часть прелести теряете. sql же там строка, т.е. всю строгую типизацию херите, все описки в рантайме получите.
22 апр 21, 22:53    [22312843]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник, если хочешь пообщаться про Rich Model, выдели это в отдельную тему. Я шестой год пишу проект на Rich Model, очень доволен. Но я сравниваю по больше части с Transaction Script'ом, на нем проект такой сложности не представляю как бы мы писали..
забыл ник
ООП сгинет в пучине в ближайшее десятилетие
Увы, ООП толком и не жило. Во всяком случае на Java. Вокруг в основном процедурщина.

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

Откуда:
Сообщений: 3471
hck2

ну все таки написать тест и продебажить отдельные методы - много, много удобней, чем портянки в блокноте парсить умозрительно. а то что вы spark.sql() юзаете, так вы же большую часть прелести теряете. sql же там строка, т.е. всю строгую типизацию херите, все описки в рантайме получите.

Ну многое конечно зависит от сложности бизнес-логики и от юзеров системы, пожалуй соглашусь что я слишком категоричен, но большинство проектов в моей конторе типовые, они сводятся к тому что заказчики, американские большие компании, переводят свою структуру на Big Data и Cloud технологии, большинство спецов там - бизнес-аналитики, индусского происхождения, которые хорошо шарят в бизнес-логике и зачастую в sql, но абсолютно не шарят в general language programming. Так вот - главная фишка спарка не в том чтобы хорошо написать класс и красиво разложить по полочкам логику, а дать возможность бизнес-аналитикам и всяким датасайнсерам запустить алгоритм на больших данных и получить результат за разумное время. Ну а дальше его уже можно сделать production-ready обычными программистами, если понадобится.
А зачастуб случается, что бизнес-логика резко и часто меняется, и все твои разложенные методы идут лесом, когда сторона join меняется с left на right. Дополнительным плюсом SQL-портянки является то что можно за минуту определить все датасорсы и какое поле откуда тянется, в отличие от "изящных" one-liners filter.select.join.map(_.join(b.withColumn().select().filter
Но тестировать и типобезопасность это конечно больновато, и мы не сразу пришли к spark.sql() - жизнь по итогу заставила, так по итогу продуктивнее
22 апр 21, 23:10    [22312850]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

Откуда:
Сообщений: 3471
Stanislav Bashkyrtsev
Увы, ООП толком и не жило. Во всяком случае на Java. Вокруг в основном процедурщина.

Ну вклассическом понимание ООП никогда и не было в Java, имею вводу модель Алана Кэя. Иронично, но наиболее похожим является реализация на акторах в Erlang.
Что касается Java - уже лет 10 прошу привести пример правильного ООП, да вот проблема в том что эксперты не могут договориться что же такое правильное:) А все потому что это чистое бла-бла и гуманитарщина, не имеющая научной и математической основы и каждый лепит во что горазд и обвиняет другого в еретическом ООП.
Без иронии, хотелось бы увидеть может хоть на этот раз true-oop проект успешный
22 апр 21, 23:14    [22312851]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
hck2
Member

Откуда:
Сообщений: 54
забыл ник

Ну многое конечно зависит от сложности бизнес-логики и от юзеров системы, пожалуй соглашусь что я слишком категоричен, но большинство проектов в моей конторе типовые, они сводятся к тому что заказчики, американские большие компании, переводят свою структуру на Big Data и Cloud технологии, большинство спецов там - бизнес-аналитики, индусского происхождения, которые хорошо шарят в бизнес-логике и зачастую в sql, но абсолютно не шарят в general language programming. Так вот - главная фишка спарка не в том чтобы хорошо написать класс и красиво разложить по полочкам логику, а дать возможность бизнес-аналитикам и всяким датасайнсерам запустить алгоритм на больших данных и получить результат за разумное время. Ну а дальше его уже можно сделать production-ready обычными программистами, если понадобится.
А зачастуб случается, что бизнес-логика резко и часто меняется, и все твои разложенные методы идут лесом, когда сторона join меняется с left на right. Дополнительным плюсом SQL-портянки является то что можно за минуту определить все датасорсы и какое поле откуда тянется, в отличие от "изящных" one-liners filter.select.join.map(_.join(b.withColumn().select().filter
Но тестировать и типобезопасность это конечно больновато, и мы не сразу пришли к spark.sql() - жизнь по итогу заставила, так по итогу продуктивнее

ну так мы обсуждаем не ваших индусов, которым проще нафигачить стринг с запросом который вылетет в рантайме, но зато быстро тикет закрыть, а сам принцип. как могла бы выглядеть вменяемая замена орма. там где не требовалось бы простыни литералов в едином блоке, где можно было бы разбить на методы и на них тесты написать.
я не спорю, что индусу дай спарк он и в спарке " filter.select.join.map(_.join(b.withColumn().select().filter " нахреначит единой строкой. но тут я хотя бы могу выдрать кусок и запихнуть в метод, нарисовать тест. в промежутке запросить план на мутный кусок. а в sql хрен ты в большой системе что-то найдешь и уж тем более подправишь глобально. датасорс ваш это вью, который джоин из двух других вью, а те джоин еще пяти и в условиях джоина функции. все мы знаем что в лучшем случае можно понять логику и нарисовать с нуля свои три этажа, но уже не вью а cte.
22 апр 21, 23:35    [22312857]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник
проблема в том что эксперты не могут договориться что же такое правильное:)
Так в любом вопросе - есть теоретическая часть где философы бьются над определением идеалов, а есть прикладная часть, когда нужно сделать работу. И порою надо срезать углы, где-то надо подумать про производительность и отойти от идеалов, где-то заиспользовать какую-то некрасивую библиотеку, а где-то просто время поджимает и некогда думать.
забыл ник
Без иронии, хотелось бы увидеть может хоть на этот раз true-oop проект успешный
Ну я вот пилю один большой проект в глубоком продакшнне и один по-меньше, которым еще никто не начал пользоваться. В обоих случаях доволен. Но конечно это все закрыто. Не знаю конечно как определить "успешный", но стейкхолдеры и пользователи нас обожают.

Я использую что-то вроде DDD. Т.е. обращение к внешним хранилищам находится в сервисах/репозиториях, они собирают доменную модель, ну и вызывают у нее какой-то метод. А этот метод уже может вызывать тучу всего внутри модели, там уже десятки тыщ строк кода могут выполняться. Очень удобно тестировать: 7К тестов проходят за 10-15 мин, при том что мок-фреймворки мы не используем.

Ну и я не знаю что бы я делал без Хиба в таком проекте.
22 апр 21, 23:35    [22312858]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

Откуда:
Сообщений: 3471
hck2

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

SLick уже почти 10 лет, ну не летит оно, не летит, как хотелось бы, можно с этим спорить, можно с пеной у рта доказывать всю правильность идеи, но нет.
По spark - если у вас в основном батч компутейшен, то логика разумная, если же анализ данных - то spark sql, скорее всего у вас первый вариант. Только по моему немаленькому опыту, а это работа с 3 представителями из Fortune 500 - спарк все же продвигается как унифицированная платформа по обаботке и анализу данных в облаке, ориентированная на бизнес-аналитика с базовыми знаниями программирования, отсюда и растет популярность питона, который я терпеть не могу и всякие zeppelin с notebooks
22 апр 21, 23:41    [22312860]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

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


Я использую что-то вроде DDD. Т.е. обращение к внешним хранилищам находится в сервисах/репозиториях, они собирают доменную модель, ну и вызывают у нее какой-то метод. А этот метод уже может вызывать тучу всего внутри модели, там уже десятки тыщ строк кода могут выполняться. Очень удобно тестировать: 7К тестов проходят за 10-15 мин, при том что мок-фреймворки мы не используем.

Ну и я не знаю что бы я делал без Хиба в таком проекте.

Ну и что из этого Rich Model?(против самого подхода ничего не имею). Где ваши умные объекты? Вы просто правильно определили бизнес-агрегаты и разбили на модули. Как были сервисы а-ля Transaction Script так они и остались. Более того, DDD можно и нужно реализовывать на функциональной парадигме без каких-либо проблем, просто надо разделять данные(собранные в класс или record) и логику, которая по факту находится в stateless объектах и название класса или сервиса - всего лишь namespace, давайте говорить честно. И успешно выходить с этим в продакшен. Положа руку на сердце - сколько раз вы в своей жизни брали класс с одного проекта и использовали в другом(особенно с rich логикой) - максимум FileUtils какой:) А я свои ФП либы и утилсы постоянно таскаю ссобой без единого изменения.
Ничего не имею протв вас, но советую снять шоры с глаз по поводу ООП, это всего лишь маркетинг. DDD - ничего не имею против.
Ну и собственно касаясь основной темы, хибера - да, он был полезен некоторое время, особенно когда были модны в энтерпрайзе админки к формам и таблицам на веб-интерфейсе, с простым CRUD и парой-тройкой связей. Но время безвовзвратно ушло, да и инстурменты появились получше - тот же jOQQ например, если так хочется объектности, хотя и он нафиг не нужен при хорошей либе делающей удобным JDBC.
22 апр 21, 23:51    [22312861]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник
Ну и что из этого Rich Model?
Ну вот все что я описал. Если ты о том что вызовы к хранилищу/интеграциям не находятся в самой модели - дак это не обязательное условие (хотя приверженцы Rich Model правда часто изображают ее именно так). Вот что Фаулер об этом пишет:
Fowler
One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn't an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
В общем, главное чтоб сущности не были просто структурами, чтоб в них и находилась предметная логика. В моем случае это 90% кода приложения.
забыл ник
Как были сервисы а-ля Transaction Script так они и остались
У классов Transaction Script'a нет состояния. Вот он как раз просто список функций, а не полноценный класс (данные+методы).
забыл ник
Положа руку на сердце - сколько раз вы в своей жизни брали класс с одного проекта и использовали в другом(особенно с rich логикой) - максимум FileUtils какой
Ээ.. не понял как это связано с обсуждением. Обычно код очень специфичен для конкретного продукта. Собсно если это не так, то это скорей всего так се код. Есть конечно что-то прям очень фундаментальное для предметной области, что нужно многим приложениям - таких классов я десятки переносил.
забыл ник
хибера - да, он был полезен некоторое время, особенно когда были модны в энтерпрайзе админки к формам и таблицам на веб-интерфейсе, с простым CRUD и парой-тройкой связей
CRUD и на обычном JDBC не сложно реализовать, там ORM не критичен.
забыл ник
тот же jOQQ например, если так хочется объектности, хотя и он нафиг не нужен при хорошей либе делающей удобным JDBC.
JOOQ/JDBC не следят за изменениями в объектах. Я не знаю как без dirty checks сложную логику в модель можно поместить. Кстати, если две сущности ссылаются на один и тот же объект, JOOQ сможет не создавать каждому по копии?

Сообщение было отредактировано: 23 апр 21, 00:10
23 апр 21, 00:14    [22312866]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
забыл ник
Member

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

В общем, главное чтоб сущности не были просто структурами, чтоб в них и находилась предметная логика. В моем случае это 90% кода приложения.
У классов Transaction Script'a нет состояния. Вот он как раз просто список функций, а не полноценный класс (данные+методы).

А зачем все же мешать данные и логику в одном месте? Особенно в свете тренда java экспертов, восхваляющих иммутабельность? Плюсов нет никаких, та же инкапсуляция достигается через сервисный слой + иммутабл records, но принося при этом кучу проблем. Любой мутабельный стейт вносит в программы понятие времени, когда результат работы кода зависит от времени его вызова, это просто фантастически увеличивает количество возможных состояний системы и ведет в итоге к космической сложности и краху проектов. Зачем цепляться за этот миф?

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

Одним из обещаний ООП была легкость создания small reusable objects. а-ля компоненты. Могу гарантировать что вы ни одного класса со стейтом не перенесли между проектами, в этом и весь мой поинт.
JOOQ/JDBC не следят за изменениями в объектах. Я не знаю как без dirty checks сложную логику в модель можно поместить. Кстати, если две сущности ссылаются на один и тот же объект, JOOQ сможет не создавать каждому по копии?

Понятия не имею, если честно, мне ни dirty-checks ни мутабельные объекты не впились, смотрел jOQQ только из спортивного интереса. Честно говоря не могу придумать пример где это может быть полезно, было бы интересно узнать доменную область ваших приложений что вы без них прям никак.
23 апр 21, 00:35    [22312871]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
забыл ник
А зачем все же мешать данные и логику в одном месте? Особенно в свете тренда java экспертов, восхваляющих иммутабельность?
Не понял.. как иммутабельность противоречит состоянию+логике? Какой-то процент классов которые мы создаем в проекте спокойно умещают оба. Собсно иммутабельность именно в этом контексте и используется - когда внутри класса есть данные, но их никак не поменять. Если состояния нет, то это просто stateless классы. Вот их мы не любим.

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

забыл ник
Плюсов нет никаких, та же инкапсуляция достигается через сервисный слой + иммутабл records, но принося при этом кучу проблем.
Не принося проблем? Ну я сходу могу сказать что тестировать такое я не захочу: либо прийдется использовать моки (нарушая инкапсуляцию потому как теперь в тестах мы знаем какие классы и методы дергает SUT; плюс сама подготовка моков, да и тот факт что мы теперь тестируем моки вместо нашего кода), либо писать высокоуровневые тесты которые сложней и медленней. Таких проектов я много видел..

Ну и иммутабл records - это противоположность инкапсуляции. Все данные торчат наружу.
забыл ник
Любой мутабельный стейт вносит в программы понятие времени, когда результат работы кода зависит от времени его вызова, это просто фантастически увеличивает количество возможных состояний системы и ведет в итоге к космической сложности и краху проектов. Зачем цепляться за этот миф?
Не знаю зачем ты цепляешься за этот миф :) Immutable объекты - это хорошо, я их обожаю. И многие ООП пуристы считают что все объекты должны быть immutable. Но сам я в это не верю.. Нередко это лишний геморрой, потому как для их "модификации" (копирование старого состояния + добавления нового) требует много доп кода. Ну и это однозначно не всегда производительно (но бывает и наоборот - тогда иммутабельность это особенно радует глаз). И это при том что вся доменная модель никогда не шарится между потоками.

забыл ник
Одним из обещаний ООП была легкость создания small reusable objects. а-ля компоненты. Могу гарантировать что вы ни одного класса со стейтом не перенесли между проектами, в этом и весь мой поинт.
Reusable внутри проекта, да. Т.е. вместо создания 10 классов под каждый случай мы можем создать 1 универсальную абстракцию. Это да, когда так получается - прям радуется сердце. Но за пределами проекта нужны другие объекты которые решают другие проблемы.

Но между проектами в одной предметной области часто есть одни и те же примитивы типа Деньги. Так же бывают общие проблемы типа экспорта в Excel. И те, и другие получается переносить между проектами. И они все с состоянием. У меня в проекте таких примитивов к примеру штук 20 - все они с легкостью переносятся в другие проекты. В общем-то надо будет библиотеки из них создать в когда-нибудь..
забыл ник
мне ни dirty-checks ни мутабельные объекты не впились, смотрел jOQQ только из спортивного интереса. Честно говоря не могу придумать пример где это может быть полезно, было бы интересно узнать доменную область ваших приложений что вы без них прям никак.
Dirty check начинает быть важным когда объекты таки мутабельны и начинают меняться внутри. Чтоб обновить базу нужно понимать какие объекты поменялись/удалились/добавились. Я вижу только три способа это сделать в ООП:
1. Полностью иммутабельные объекты. В БД никогда не уходит UPDATE - только INSERT'ы. Во многих случаях это будет значить низкую производительность.
2. Ручной dirty check: мы где-то сохраняем состояние - какие объекты обновились. Т.е. каждый раз когда кто-то меняется - он записывает себя/свои ассоциации куда-то в коллекцию поменянных объектов.
3. Ну и то что предоставляет ORM - это автоматический dirty check. Мы сами ничего не трекаем - просто изменяем объекты как нам надо.

Я работаю в наукоемкой отрасли (химия/биология/фарма), но тут никакой специфики нет..

Сообщение было отредактировано: 23 апр 21, 05:27
23 апр 21, 05:33    [22312888]     Ответить | Цитировать Сообщить модератору
 Re: Нужен ли нам ORM?  [new]
Stanislav Bashkyrtsev
Member

Откуда: СПб
Сообщений: 137
упс, сообщение никак не удалить :(

Сообщение было отредактировано: 23 апр 21, 05:30
23 апр 21, 05:37    [22312889]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 18   вперед  Ctrl
Все форумы / Java Ответить