Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, meowth, Вы писали:
S>С точки зрения предметной области, и то и другое — всего лишь несущественные подробности реализации. Поскольку один хрен в основании пирамиды лежат таблицы СУБД, полезность любой промежуточной прослойки требует отдельного доказательства.
Предметной области глубоко пофик на то, что там за таблицы.
S>Простейший пример — если есть сценарий, в котором нужно найти, к примеру, список категорий товаров, заказанных определённым покупателем за определённый период времени, то в SQL есть простой и однозначный способ описать эту задачу в терминах конкретных таблиц и связей. ORM-прослойка не даёт в этом плане ничего нового;
Продолжайте писать в терминах таблиц, я ж не принуждаю никого. Это вы пенитесь, что rich -- это плохо.
S>наоборот — она требует наличия в кэше большого количества промежуточных объектов, которые, в общем-то, в исходную постановку задачи не входили.
Если ваш аргумент заключается в том, что rich требует кеша -- можете сразу на него забить (на аргумент). Это все равно, что спорить, что автомобиль плох, потому что требует бензин для работы.
S>Никого не интересует, что в объекте Order есть коллекция Items, каждая из которых связана с объектом Product, из которого торчит ссылка на Category. Почему? Да потому, что в контексте этой задачи никакого поведения у объектов нету.
Вы придумали задачу, я думаю здесь спорить бессмысленно, потому что там есть только то, что вы хотите.
S>Прекрасно. Вот в задаче выше, anemic model вообще не загрузит в сервер ни одного Order и ни одного OrderItem. Причём, что характерно, без резервирования в аппсервере мегабайт памяти под эти объекты. И без расходов трафика на поддержание когерентности реплик кэша между узлами фармы.
Очень интересно, как оно будет с этими данными работать, если не загрузит их себе в память из БД.
Про реплицированный кеш я ничего не говорил пока, не путайте одно с другим.
S>>Что такое "запрос рейс+аэропорт"? Можно пример SQL?
WF>Примерно так: WF>
WF>select * from SEGMENT S inner join AIRPORT A on S.DEP_AIRPORT = A.ID where S.ID = 100;
WF>
S>>Непонятно. Имеем два запроса: 1 запрос на детали рейса, 1 запрос на детали аэропорта. Вот у этого второго запроса есть lifetime; который достаточно велик для того, чтобы он жил в кэше.
WF>Да, именно так у нас (с участием LL+кеш) и есть. Два запроса, второй живёт в кеше. Второй запрос = выборка аэропорта по id, потому в данном случае «закешированный запрос» == «закешированный объект».
Приведите пример юзкейса где понадобится именно такая выборка без дополнительных проекций.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, meowth, Вы писали:
M>>>Здравствуйте, gandjustas, Вы писали:
WF>>>>>1 обращение не всегда хорошо. Может оказаться, что одна часть выборки очень хорошо кешируется — зачем тогда её каждый раз выбирать запросом, лишний раз нагружать СУБД? А в случае LL достаточно навесить кеширование на связанную сущность — и она выберется лишь один раз, дальше будет так же по одной выборке.
G>>>>Такое работает только для справочных данных. Их вообще можно кешировать на клиенте.
M>>>Может, я вас не понял, но тут имхо вы не правы. До тех пор, пока кеш для связанных сущностей (например, коллекции дочерних сущностей) не был сброшен, для навигации внутри бизнес-логики они выбираются из кеша, т.к. навигация к ним осуществляется по id, а identity map отрабатывает эти моменты.
G>>Для этого никакой кеши не нужен. Достаточно один раз загрузить сущность со связанными (выполняется join) на запрос и потом ходить по связанным сущностям сколько влезет. При этом если кто-то другой в этот момент поменяет связанную колеекцию, то фантомов у вас не появится (оптимистичная блокировка против них бессильна).
M>Не, ты меня не понял ИМХО. Вот в одном методе бизнес логики (или сервиса в твоей интерпретации) ты виртуозным join подгрузил эти связанные сущности. (я уже молчу про то, что сервис в таком случае должен знать схему БД, чтобы стрелять joinами)
А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность.
M>Затем вышел из сервиса А, и зашел в другой (B), в котором понадобились те же связанные сущности. Как быть -- загружать из БД опять? Как это обойти без кеша?
Если два сервиса пользуются одиними и теми же данными, то данные им передает вызывающий код.
Здравствуйте, gandjustas, Вы писали:
G>А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность.
В одном случае о схеме знает специальная инфраструктура, которая в любом случае о ней знает, в другом сервисы логики.
G>Если два сервиса пользуются одиними и теми же данными, то данные им передает вызывающий код.
Т.е. вызывающий код должен знать все данные которые понадобятся сервисам для их логики?
Здравствуйте, gandjustas, Вы писали:
G>Приведите пример юзкейса где понадобится именно такая выборка без дополнительных проекций.
Пример: генерация текста (текстов) сообщений. Заранее неизвестно, какие шаблоны будут использованы и, соответственно, какая точная проекция нужна.
Цикл такой:
1) Выборка рейса.
2) Обновление по некоторым правилам.
3) Узнаем шаблоны, которые нужно использовать для генерации текстового сообщения.
4) Генерируем сообщения, отправляем.
Здравствуйте, WFrag, Вы писали: WF>Вот ты сам несколькими постами выше утверждал, что себестоимость запроса сильно зависит от набора полей. Зачем выбирать +N полей, если их можно взять из местного кеша?
Можно. WF> Да, можно было это делать явно. Загружаем «рейс», делаем запрос к кешу, выбираем «аэропорт», формируем текст сообщения по шпблону.
Ну, к примеру, оба запроса всегда проходят через кэш. Просто у одного из них стоит cahe duration более длинная, чем у другого. WF>Но зачем, если проще просто объявить аэропорт связанной с рейсом сущностью, и пометить как «кешируемо»? А ORM всё сделает за нас.
Это не проще. Аэропорт никак не связан с рейсом. ORM будет делать за вас не то, что нужно.
WF>Не понял мысли. Предлагается вообще не хранить словарную сущность («аэропорт») в БД?
Предлагается не полагаться на наличие этой сущности в кэше. Понадобилась — попросил.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
M>>Не, ты меня не понял ИМХО. Вот в одном методе бизнес логики (или сервиса в твоей интерпретации) ты виртуозным join подгрузил эти связанные сущности. (я уже молчу про то, что сервис в таком случае должен знать схему БД, чтобы стрелять joinами) G>А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность.
Чтобы делать или не делать LL, код не нужно править. Можно отключить или включить LL в конфиге, причем для тех сущностей, которых надо. Ну и там же указать, подтягивать ли их отдельным запросом или join'ить (если это eager load). Ну и естессно, кеш работает в любом случае
M>>Затем вышел из сервиса А, и зашел в другой (B), в котором понадобились те же связанные сущности. Как быть -- загружать из БД опять? Как это обойти без кеша? G>Если два сервиса пользуются одними и теми же данными, то данные им передает вызывающий код.
Как-то очень грустно получается: N сервисов связаны не только контрактом сущностей, с которыми они работают, но и общими данными с M клиентами, которые их вызывают. Причем вызывающий код должен точно знать до состава полей, какие данные понадобятся сервисам, чтобы не загрузить лишнего. А если сервис переписан и требует дополнительных полей, то придется переписать и всех его клиентов. При этом по контракту сервиса и непонятно, какие данные ему понадобятся, а какие нет -- скажем, если ему передается Order, надо ли грузить OrderItems.
Не, я понимаю, что такова идеология "чистый код + чистые данные раздельно" и по-другому никак, но, в общем, думаю, что это слабоватое место.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность. Z>В одном случае о схеме знает специальная инфраструктура, которая в любом случае о ней знает, в другом сервисы логики.
Загрузкой данных всегда занимается специальная инфраструктура — различные ORM.
G>>Если два сервиса пользуются одиними и теми же данными, то данные им передает вызывающий код. Z>Т.е. вызывающий код должен знать все данные которые понадобятся сервисам для их логики?
Естественно.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, gandjustas, Вы писали:
G>>Приведите пример юзкейса где понадобится именно такая выборка без дополнительных проекций.
WF>Пример: генерация текста (текстов) сообщений. Заранее неизвестно, какие шаблоны будут использованы и, соответственно, какая точная проекция нужна.
WF>Цикл такой:
WF>1) Выборка рейса. WF>2) Обновление по некоторым правилам. WF>3) Узнаем шаблоны, которые нужно использовать для генерации текстового сообщения. WF>4) Генерируем сообщения, отправляем.
1-2 и 3-4 вроде как не связаны. В 3-4 вполне возможно строить динамически проекцию.
Здравствуйте, gandjustas, Вы писали:
G>Загрузкой данных всегда занимается специальная инфраструктура — различные ORM.
Только в анемичной модели в DAL приходится хардкодить джойны.
Z>>Т.е. вызывающий код должен знать все данные которые понадобятся сервисам для их логики? G>Естественно.
Здравствуйте, meowth, Вы писали:
S>>Простейший пример — если есть сценарий, в котором нужно найти, к примеру, список категорий товаров, заказанных определённым покупателем за определённый период времени, то в SQL есть простой и однозначный способ описать эту задачу в терминах конкретных таблиц и связей. ORM-прослойка не даёт в этом плане ничего нового; M>Продолжайте писать в терминах таблиц, я ж не принуждаю никого. Это вы пенитесь, что rich -- это плохо.
Я не пенюсь. Я пытаюсь объяснить очевидные вещи людям, спорящим с тривиальностиями.
M>Если ваш аргумент заключается в том, что rich требует кеша -- можете сразу на него забить (на аргумент). Это все равно, что спорить, что автомобиль плох, потому что требует бензин для работы.
Аналогия плоха. Но это неважно. Если вы хотите поговорить про кэш — пожалуйста, можем поговорить о недостатках кэша. Не хотите говорить о недостатках кэша — можем поговорить о неотъемлемых проблемах Rich model.
M>Вы придумали задачу, я думаю здесь спорить бессмысленно, потому что там есть только то, что вы хотите.
Конечно бессмысленно. Потому что в этой задаче анемик рвет вашу рич на тряпки. А теперь попробуйте придумать адекватный обратный пример. Окажется, что в лучшем случае рич будет играть 1:1 с анемик по объему кода, стоимости сопровождения, и эффективности реализации.
M>Очень интересно, как оно будет с этими данными работать, если не загрузит их себе в память из БД.
Интересно — поясняю: в запросе не были нужны эти данные. Перечитайте задачу еще раз. А, значит, и "работать" с ними не надо. И бояться, что кэш устарел, тоже не надо. И тратиться на обновление этого кэша — опять не надо. Ничего не надо. Всё, что надо — это список строк. И простая функция, которая отображает три параметра в список строк. Трафик между клиентом и сервером — минимален.
Эффективность — превосходная. Повторное исполнение этого запроса будет идти в памяти СУБД, потому что все нужные страницы Order/OrderItem подняты в его кэш в любом случае — независимо от анемичности модели в аппсервере. Тот кэш, про который вы говорите — это еще одна копия тех же данных. Зачем она вам? M>Про реплицированный кеш я ничего не говорил пока, не путайте одно с другим.
А вам придется про него говорить, как только нагрузка вынудит вас перевести аппсервер на кластер. Никуда вы не денетесь. Опять же, из-за того, что больше работы делается в коде апп-сервера, вам придется это делать раньше, чем анемичной модели.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Не, ты меня не понял ИМХО. Вот в одном методе бизнес логики (или сервиса в твоей интерпретации) ты виртуозным join подгрузил эти связанные сущности. (я уже молчу про то, что сервис в таком случае должен знать схему БД, чтобы стрелять joinами) G>>А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность. M>Чтобы делать или не делать LL, код не нужно править. Можно отключить или включить LL в конфиге, причем для тех сущностей, которых надо. Ну и там же указать, подтягивать ли их отдельным запросом или join'ить (если это eager load). Ну и естессно, кеш работает в любом случае
Без составления проекци толку нету.
Кстати как в таком случае запросы с аггрегацией работают?
M>>>Затем вышел из сервиса А, и зашел в другой (B), в котором понадобились те же связанные сущности. Как быть -- загружать из БД опять? Как это обойти без кеша? G>>Если два сервиса пользуются одними и теми же данными, то данные им передает вызывающий код. M>Как-то очень грустно получается: N сервисов связаны не только контрактом сущностей, с которыми они работают, но и общими данными с M клиентами, которые их вызывают. Причем вызывающий код должен точно знать до состава полей, какие данные понадобятся сервисам, чтобы не загрузить лишнего. А если сервис переписан и требует дополнительных полей, то придется переписать и всех его клиентов. При этом по контракту сервиса и непонятно, какие данные ему понадобятся, а какие нет -- скажем, если ему передается Order, надо ли грузить OrderItems.
Есть такая страная вещь как композиция. Например нужно какому либо сервсиу работать с деталями заказа, то ему передаются только детали заказа. Другому нужен order, то ему передается только он.
Кучка таких мелкийх сервисов собирается в более крупный, который соотвествует бизнес-транзакции типа "добавить айтем к ордеру". Соответственно внутри этого сервиса происходит все получение данных.
M>Не, я понимаю, что такова идеология "чистый код + чистые данные раздельно" и по-другому никак, но, в общем, думаю, что это слабоватое место.
Это смотря как писать. Функциональная композиция рулит.
А ЗД или другой код более высокого уровня образается только к сервисам которые отдают данные и не имеют побочных эффектов или передают запрос на изменение данных. (Command-Query Separation в чистом виде).
Здравствуйте, Sinclair, Вы писали:
S>Правильный цикл: S>1. Парсим шаблон, выясняем нужные данные S>2. Строим набор запросов, вытаскивающих нужные данные S>3. Прогоняем запросы через кэш.
Нет, так не выйдет. Мы не знаем шаблон(-ы), пока не обновим запись. В моём списке пункт 3 не зря идёт после 2. Более того, на этапе 2 мы тоже не особо знаем, какие данные нужны, т.к есть такая нехорошая точка расширения под названием «noise filter», которая может на основании любых фантазий о записи (включая историю изменений записи) отменить её изменение, но это (в теории) решаемо добавлением метода к фильтру, который бы выяснял, что ему надо.
И самое главное, не очень понятно, зачем это нужно. Очень похоже на premature optimization. По текущим тестам, сейчас тормозят совсем не эти запросы, тем более, что поля все идут из одной строки таблицы (а остальные поля идут из кеша словарных данных)
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Загрузкой данных всегда занимается специальная инфраструктура — различные ORM. Z>Только в анемичной модели в DAL приходится хардкодить джойны.
Джоины хардкодятся просто нереально тяжко.
Вот был у меня запрос на вытаскиванпе ордера
var q = from o in _orders
where o.Id == someId
select o;
А тут мне понадобилось получать ордер вместе с айтемами. И я поменял почти полпрограммы чтобы получить такой эффект.
var q = from o in _orders.With(ord => ord.OrderItems)
where o.Id == someId
select o;
Z>>>Т.е. вызывающий код должен знать все данные которые понадобятся сервисам для их логики? G>>Естественно. Z>Хороший аргумент против ADM.
Вы не понимаетео чем говорите.
Здравствуйте, gandjustas, Вы писали:
WF>>Пример: генерация текста (текстов) сообщений. Заранее неизвестно, какие шаблоны будут использованы и, соответственно, какая точная проекция нужна.
WF>>Цикл такой:
WF>>1) Выборка рейса. WF>>2) Обновление по некоторым правилам. WF>>3) Узнаем шаблоны, которые нужно использовать для генерации текстового сообщения. WF>>4) Генерируем сообщения, отправляем.
G>1-2 и 3-4 вроде как не связаны. В 3-4 вполне возможно строить динамически проекцию.
Связаны, в том смысле, что только после обновления записи мы знаем какие шаблоны нам нужны (и нужны ли вообще). Грубо говоря, смысл такой, что каждое изменение в пункте 2 (их может быть несколько) генерирует событие (которое зависит от старого состояния), по которому мы ищем привязанные сообщения.
Например, если реальное время отрыва от полосы было NULL, а стало не NULL и старое состояние было CHECK_IN, то генерируется событие DEPARTED. К которому может быть привязано любое сообщение. Например, «Рейс ${segment.flightNumber} улетел из ${segment.depAirport.name} (${segment.depAirport.iata})».
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, meowth, Вы писали:
M>>Здравствуйте, gandjustas, Вы писали:
M>>>>Не, ты меня не понял ИМХО. Вот в одном методе бизнес логики (или сервиса в твоей интерпретации) ты виртуозным join подгрузил эти связанные сущности. (я уже молчу про то, что сервис в таком случае должен знать схему БД, чтобы стрелять joinами) G>>>А чтобы LL делать схему знать не надо? Причем не кому-либо, а самому объекту с данными. Вот тебе и связность. M>>Чтобы делать или не делать LL, код не нужно править. Можно отключить или включить LL в конфиге, причем для тех сущностей, которых надо. Ну и там же указать, подтягивать ли их отдельным запросом или join'ить (если это eager load). Ну и естессно, кеш работает в любом случае G>Без составления проекци толку нету.
Толку в чем?
G>Кстати как в таком случае запросы с аггрегацией работают?
Так же, как и раньше.
G>>>Если два сервиса пользуются одними и теми же данными, то данные им передает вызывающий код. M>>Как-то очень грустно получается: N сервисов связаны не только контрактом сущностей, с которыми они работают, но и общими данными с M клиентами, которые их вызывают. Причем вызывающий код должен точно знать до состава полей, какие данные понадобятся сервисам, чтобы не загрузить лишнего. А если сервис переписан и требует дополнительных полей, то придется переписать и всех его клиентов. При этом по контракту сервиса и непонятно, какие данные ему понадобятся, а какие нет -- скажем, если ему передается Order, надо ли грузить OrderItems. G>Есть такая страная вещь как композиция. Например нужно какому либо сервсиу работать с деталями заказа, то ему передаются только детали заказа. Другому нужен order, то ему передается только он. G>Кучка таких мелкийх сервисов собирается в более крупный, который соотвествует бизнес-транзакции типа "добавить айтем к ордеру".
Вам счас не об этом говорят. Функциональную композицию никто не отменял, и фасадная организация a la transactional script -- это нормально. Говорят о том, что сервисы становятся хрупкими и еще код, который мог бы находиться в инфраструктуре, теперь надо пихать в сервис. G>Соответственно внутри этого сервиса происходит все получение данных.
Понадобятся ли они на самом деле -- это вопрос, на который нельзя ответить.
M>>Не, я понимаю, что такова идеология "чистый код + чистые данные раздельно" и по-другому никак, но, в общем, думаю, что это слабоватое место. G>Это смотря как писать. Функциональная композиция рулит.
Если писать "смотря как", то можно на любой модели сделать конфетку ФК тут не при чем. G>А ЗД или другой код более высокого уровня образается только к сервисам которые отдают данные и не имеют побочных эффектов или передают запрос на изменение данных. (Command-Query Separation в чистом виде).
Чтобы они отдавали данные, им нужно знать, какие данные отдавать. Причем договориться еще с тучей сервисов, что приедут именно нужные данные.
Здравствуйте, gandjustas, Вы писали:
G>А тут мне понадобилось получать ордер вместе с айтемами. И я поменял почти полпрограммы чтобы получить такой эффект.
G>
G>var q = from o in _orders.With(ord => ord.OrderItems)
G>
aggregation root detected, а сколько было на него вылито грязи?
G>Вы не понимаетео чем говорите.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, gandjustas, Вы писали:
WF>>>Пример: генерация текста (текстов) сообщений. Заранее неизвестно, какие шаблоны будут использованы и, соответственно, какая точная проекция нужна.
WF>>>Цикл такой:
WF>>>1) Выборка рейса. WF>>>2) Обновление по некоторым правилам. WF>>>3) Узнаем шаблоны, которые нужно использовать для генерации текстового сообщения. WF>>>4) Генерируем сообщения, отправляем.
G>>1-2 и 3-4 вроде как не связаны. В 3-4 вполне возможно строить динамически проекцию.
WF>Связаны, в том смысле, что только после обновления записи мы знаем какие шаблоны нам нужны (и нужны ли вообще). Грубо говоря, смысл такой, что каждое изменение в пункте 2 (их может быть несколько) генерирует событие (которое зависит от старого состояния), по которому мы ищем привязанные сообщения.
WF>Например, если реальное время отрыва от полосы было NULL, а стало не NULL и старое состояние было CHECK_IN, то генерируется событие DEPARTED. К которому может быть привязано любое сообщение. Например, «Рейс ${segment.flightNumber} улетел из ${segment.depAirport.name} (${segment.depAirport.iata})».
Все равно не пойму в каком юзкейсе такое всречается. А то у вас data-driven в прямом смысле приложение получается, сценарии работы зависят от изменения данных. (хотя реально наоборот происходит)
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>А тут мне понадобилось получать ордер вместе с айтемами. И я поменял почти полпрограммы чтобы получить такой эффект.
G>>
G>>var q = from o in _orders.With(ord => ord.OrderItems)
G>>
Z>aggregation root detected, а сколько было на него вылито грязи?
какой aggregation root? Просто данные и связи между ними.
Или это уже симптомы человека с молотком?
