Здравствуйте, Sinclair, Вы писали:
S>Прекрасно. То есть мы всё-таки поднимаем все заказы за период. Поздравляю, быстродействие падает линейно с увеличением диапазона дат. Да, конечно же N ожидается реально большим. Ну, не там, где разработчик это тестирует, а в боевой базе.
Тупой императивный код можно накрутить в обеих моделях, да в рич это делается чуть проще.
S>Кстати, как работает ваш код — что там за {categories} в параметрах, и что за фильтр вы собрались накладывать на o.Items? S>По-видимому, императивная запись провоцирует ошибки на ровном месте.
Нее, я вообще не пытался понять твой алгоритм. Просто переписал по быстрому, в стиле доступа к рич модели, оттуда и ошибка. Хотел лишь показать, что даже тупой код доступа в рич не настолько плох, как ты пытаешься продемонстрировать. Даже не сообразил сразу, что это даже не логика, а метод из DAO, имхо, даже самые тупые программисты не пишут в DAL такой код.
S>Ничего не понимаю. Какой контракт? В анемичной модели у метода с самого начала три параметра: идентификатор кастомера, две даты. Разработчик оставлен наедине с этими параметрами. Навигация по ордерам — последнее, что придет ему в голову. Потому, что в анемичной модели для этого придется написать вручную код, который поднимает их в память.
Ганжустас утверждал, что бизнес методы в АДМ не вытаскивают данные для себя, а принимают их уже загруженными как аргументы. Сорри, сейчас из браузера, не найду конкретный пост. Ты не согласен? Альтернатива? Каждый метод в транзакции сам добывает данные для себя?
Здравствуйте, Ziaw, Вы писали: Z>Тупой императивный код можно накрутить в обеих моделях, да в рич это делается чуть проще.
Именно. Z>Нее, я вообще не пытался понять твой алгоритм. Просто переписал по быстрому, в стиле доступа к рич модели, оттуда и ошибка. Хотел лишь показать, что даже тупой код доступа в рич не настолько плох, как ты пытаешься продемонстрировать.
Ага. Но вместо этого именно что продемонстрировал, что он именно настолько плох.
Z>Ганжустас утверждал, что бизнес методы в АДМ не вытаскивают данные для себя, а принимают их уже загруженными как аргументы. Сорри, сейчас из браузера, не найду конкретный пост. Z> Ты не согласен? Альтернатива? Каждый метод в транзакции сам добывает данные для себя?
Ты его неправильно понял. Ентити не вытягивают данные для себя. А бизнес код — именно что вытягивает. В АДМ бизнес-код собственно весь и состоит из доставания данных и их модификации. Фактически, это transaction script на стероидах — то есть написанный на языке с развитыми возможностями по декомпозиции.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Z>>Тупой императивный код можно накрутить в обеих моделях, да в рич это делается чуть проще. S>Именно.
Про чуть проще я и не спорил никогда. Ключевое слово чуть.
S>Ты его неправильно понял. Ентити не вытягивают данные для себя. А бизнес код — именно что вытягивает. В АДМ бизнес-код собственно весь и состоит из доставания данных и их модификации. Фактически, это transaction script на стероидах — то есть написанный на языке с развитыми возможностями по декомпозиции.
Я его правильно понял, вот тут и возникает проблема следующая из такого тезиса
Если два сервиса пользуются одиними и теми же данными, то данные им передает вызывающий код.
Расширяем транзакшн скрипт, и понимаем, что данные которые требовались в методе А теперь нужны и в методе Б. Надо перелопачивать контракты сервисов, так как метод А раньше доставал их самостоятельно. В процессе перелопачивания мы узнаем, что метод А вызывается еще в 10 транзакшн скриптах, теперь в каждом из них придется написать код готовящий данные для метода А.
А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит.
Здравствуйте, Ziaw, Вы писали:
Z>Расширяем транзакшн скрипт, и понимаем, что данные которые требовались в методе А теперь нужны и в методе Б. Надо перелопачивать контракты сервисов, так как метод А раньше доставал их самостоятельно. В процессе перелопачивания мы узнаем, что метод А вызывается еще в 10 транзакшн скриптах, теперь в каждом из них придется написать код готовящий данные для метода А.
Не выдумывай небылицы.
Доставангие данных происходит на "верхнем уровне", полученные данные передаются методам БЛ, которые не занимаются доставанием данных.
Верхний уровень соотвествует одному transaction script, поэтому вызывается в одном, максимум двух местах. Основная часть БЛ состоит из маленьких методов, собранных в сервисы.
Z>А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит.
5n+2 вместо одного запроса.
А голова рано или позно при таком подходе болеть начинает. Кеш тоже небесконечный, чем больше объемы кешированных данных, тем больше промахов будет и чаще придется в базу бегать за даннми.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Sinclair, Вы писали:
S>>Прекрасно. То есть мы всё-таки поднимаем все заказы за период. Поздравляю, быстродействие падает линейно с увеличением диапазона дат. Да, конечно же N ожидается реально большим. Ну, не там, где разработчик это тестирует, а в боевой базе.
Z>Тупой императивный код можно накрутить в обеих моделях, да в рич это делается чуть проще.
Сложноси такие же. В рич надо чуть меньше думать, чтобы сделать тупой код.
Здравствуйте, Ziaw, Вы писали:
Z>Расширяем транзакшн скрипт, и понимаем, что данные которые требовались в методе А теперь нужны и в методе Б. Надо перелопачивать контракты сервисов, так как метод А раньше доставал их самостоятельно.
Не думаю, что это жизненный пример. Но даже если контракт и поменяется (что при нормальном проектировании маловероятно), то не составит труда отрефакторить код.
В метод A будет передаваться, допустим, IEnumerable<something>. Метод A со старой сигнатурой будет вызывать новый метод A, передавая в него тот IQueryable<something>, который раньше был зашит вовнутрь.
А наш метод B (или кто там оркеструет оба метода) будет передавать один и тот же экземпляр в оба метода, благодаря чему материализация случится только один раз. А может быть и вообще не случится — если на основе этого IQueryable формируется некий другой запрос.
Z>А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит.
Ну-ну. Вы слишком много думаете о поднятии данных, и слишком мало — о том, что на самом деле нужно сделать. Очень характерный пример с ордер айтемами тут уже был. Там, где анемичная модель провоцирует построение запросов, в которых пересчёты всех хранимых агрегатов делаются на серверной стороне, рич модель провоцирует "батч моду LL". От этой батч моды голова, конечно, не болит. Болит другое место — которым ощущаются проблемы с перформансом из-за увеличения площади локов, времени их удержания, и роста трафика между СУБД и апп-сервером.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Не выдумывай небылицы. G>Доставангие данных происходит на "верхнем уровне", полученные данные передаются методам БЛ, которые не занимаются доставанием данных. G>Верхний уровень соотвествует одному transaction script, поэтому вызывается в одном, максимум двух местах. Основная часть БЛ состоит из маленьких методов, собранных в сервисы.
Вы с Синклером договоритесь пожалуйста, или спорьте в разных ветках. Он утверждает, что данные достаются там где они понадобились, главное чтобы это где-то не находилось в классе entity.
Z>>А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит. G> G>5n+2 вместо одного запроса.
Я видимо в пустоту пишу. Повторю, пример Синклера это пример тупейшего кода. Даже просто тупой код дает N+1, такойже тупой можно написать в ADM и он будет делать столько же запросов. Это такой прием демагогии, написать тупейший пример и потом ссылаться на него как на ключевой недостаток модели, рекомендую воздерживаться от постоянного его применения, чтобы дискуссия продолжала оставаться конструктивной.
Здравствуйте, Sinclair, Вы писали:
Z>>Расширяем транзакшн скрипт, и понимаем, что данные которые требовались в методе А теперь нужны и в методе Б. Надо перелопачивать контракты сервисов, так как метод А раньше доставал их самостоятельно. S>Не думаю, что это жизненный пример. Но даже если контракт и поменяется (что при нормальном проектировании маловероятно), то не составит труда отрефакторить код.
Я с такими примерами сталкиваюсь при развитии и поддержке анемичной модели, так что жизненный.
S>В метод A будет передаваться, допустим, IEnumerable<something>. Метод A со старой сигнатурой будет вызывать новый метод A, передавая в него тот IQueryable<something>, который раньше был зашит вовнутрь. S>А наш метод B (или кто там оркеструет оба метода) будет передавать один и тот же экземпляр в оба метода, благодаря чему материализация случится только один раз. А может быть и вообще не случится — если на основе этого IQueryable формируется некий другой запрос.
Интересно. Но осталась еще проблема, надо как-то узнать, что метод А со старой сигнатурой дергает в нашей транзакции те же данные, что сейчас нужны для метода Б. Т.е. для правильно расширения скрипта нам надо протолкаться по всем вытаскиваемым во всех ветках алгоритма данным, увидеть, что метода А уже тащит те же данные, создать перегрузку, вытащить их самостоятельно, передать те же данные в метод Б. И надеяться, что требование одинаковых данных для А и Б достаточно стабильно.
Z>>А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит. S>Ну-ну. Вы слишком много думаете о поднятии данных, и слишком мало — о том, что на самом деле нужно сделать. Очень характерный пример с ордер айтемами тут уже был.
Это неверный вывод из примера. Тебе показалось, что я попытался решить задачу в рич модели, а я всего лишь показал какой будет типичный тупой код в рич модели. Он всетаки выигрывает у твоего примера примерно в 5 раз по быстродействию.
S>Там, где анемичная модель провоцирует построение запросов, в которых пересчёты всех хранимых агрегатов делаются на серверной стороне, рич модель провоцирует "батч моду LL". От этой батч моды голова, конечно, не болит. Болит другое место — которым ощущаются проблемы с перформансом из-за увеличения площади локов, времени их удержания, и роста трафика между СУБД и апп-сервером.
Я думал мы уже обсосали этот пример и я признал определенный недостаток рич модели: при написании кода в ней надо думать над тем, что достается из базы, хотя и некоторым кажется, что это необязательно. Мне это можно больше не доказывать и в каждом посте не упоминать об этом. Пожалей свое и мое время.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Не выдумывай небылицы. G>>Доставангие данных происходит на "верхнем уровне", полученные данные передаются методам БЛ, которые не занимаются доставанием данных. G>>Верхний уровень соотвествует одному transaction script, поэтому вызывается в одном, максимум двух местах. Основная часть БЛ состоит из маленьких методов, собранных в сервисы.
Z>Вы с Синклером договоритесь пожалуйста, или спорьте в разных ветках. Он утверждает, что данные достаются там где они понадобились, главное чтобы это где-то не находилось в классе entity.
Мы про разные аспекты говорим. Он про доставание данных, а я про обработку того что достали.
Z>>>А в рич модели один раз поднятые данные достаются еще раз легко и непринужденно, голова об этом не болит. G>> G>>5n+2 вместо одного запроса.
Z>Я видимо в пустоту пишу. Повторю, пример Синклера это пример тупейшего кода. Даже просто тупой код дает N+1, такойже тупой можно написать в ADM и он будет делать столько же запросов.
Не надо себя убеждать в этом.
Во-первых Linq запрос на вытягивание данных получается короче, писать тупой код становится сложнее, так как надо больше писать.
Во-вторых когда начинаешь писать запросы оказывается что часть действий может быть выполнена в БД, с гораздо большей эффективностью, чем в приложении. Объем кода от этого неувеличивается, а зачастую уменьшается так как запросы более декларативны.
Z>Это такой прием демагогии, написать тупейший пример и потом ссылаться на него как на ключевой недостаток модели, рекомендую воздерживаться от постоянного его применения, чтобы дискуссия продолжала оставаться конструктивной.
Это не просто тупой пример. Это код, который вполне может быть написан с применением LL.
Примеры которые ты выдумываешь вряд ли будут когда-то написаны, так как они сложнее правильного варианта.
Z>Интересно. Но осталась еще проблема, надо как-то узнать, что метод А со старой сигнатурой дергает в нашей транзакции те же данные, что сейчас нужны для метода Б. Т.е. для правильно расширения скрипта нам надо протолкаться по всем вытаскиваемым во всех ветках алгоритма данным, увидеть, что метода А уже тащит те же данные, создать перегрузку, вытащить их самостоятельно, передать те же данные в метод Б. И надеяться, что требование одинаковых данных для А и Б достаточно стабильно.
Это всё какая-то малоинтересная история. Что значит "узнать, что он дёргает"? Изменение делается согласованно, одним девелопером. Я не понимаю, в чём ваша проблема. Проталкиваться никуда не надо, потому что всё лежит перед глазами; все методы имеют нормальные имена и определённую семантику. Приведите пример ситуации — какой код был написан, какое изменение потребовалось, что по-вашему придётся переделать. Я постараюсь ответить, как правильно менять код в приведённом случае.
Z>Это неверный вывод из примера. Тебе показалось, что я попытался решить задачу в рич модели, а я всего лишь показал какой будет типичный тупой код в рич модели. Он всетаки выигрывает у твоего примера примерно в 5 раз по быстродействию.
У моего примера он проигрывает по быстродействию на три порядка. О чём мы вообще говорим — о бесконечно тормозном решении по сравнению с безгранично тормозным?
Я, кстати, говорил не про этот пример. А про пример, приведенный meowth, где при изменении одного OrderItem в память поднимается вся коллекция детей ордера для пересчёта total. О да, тут мы уверены в енфорсинге всех бизнес рулов. Ну, конечно, batch in LL рулит неимоверно.
Это по сравнению с кодом вида update _order set amt = (select sum(amount) from orderItem oi where orderId = @orderID) where id = @orderId. Ага-ага. Нет, у меня определенно дефицит сарказма.
Z>Я думал мы уже обсосали этот пример и я признал определенный недостаток рич модели: при написании кода в ней надо думать над тем, что достается из базы, хотя и некоторым кажется, что это необязательно. Мне это можно больше не доказывать и в каждом посте не упоминать об этом. Пожалей свое и мое время.
Не понял — а о чём тогда вы хотите поговорить? Я не собираюсь спорить с тезисом "иногда, при осторожном использовании, рич модель сосёт не слишком сильно по сравнению с анемик".
Я просто всё еще жду жызненного примера, где рич порвёт анемик на тряпки. А то получается, что супергуру рич модели приводят в её защиту примеры, которые заведомо чудовищно неэффективны. Еще раз: не как пример "наивного" кода. А как пример того, что пишет компетентный девелопер в рич модели. Кому вы хотите продать рич модель? С такой-то аргументацией?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Не надо себя убеждать в этом. G>Во-первых Linq запрос на вытягивание данных получается короче, писать тупой код становится сложнее, так как надо больше писать. G>Во-вторых когда начинаешь писать запросы оказывается что часть действий может быть выполнена в БД, с гораздо большей эффективностью, чем в приложении. Объем кода от этого неувеличивается, а зачастую уменьшается так как запросы более декларативны.
Давай так, будем говорить за себя. Рич модель лично тебя делает настолько тупым, что ты начинаешь забывать, что БД эффективнее делает запросы?
Z>>Это такой прием демагогии, написать тупейший пример и потом ссылаться на него как на ключевой недостаток модели, рекомендую воздерживаться от постоянного его применения, чтобы дискуссия продолжала оставаться конструктивной. G>Это не просто тупой пример. Это код, который вполне может быть написан с применением LL. G>Примеры которые ты выдумываешь вряд ли будут когда-то написаны, так как они сложнее правильного варианта.
Зато правильный вариант точно такой же как и линковский:
var q = s.CreateQuery(@"select distinct i.Product.Category.Name
from Order o join o.OrderItems i
where o.Date between :startDate and :endDate")
.SetParameter("startDate", startDate)
.SetParameter("endDate", endDate)
.List<string>();
А теперь напиши линковский запрос в случае, когда твоя анемик модель действительно анемик. Т.е. у объектов нет навигационные связи только в виде OrderId в OrderItem.
Здравствуйте, Sinclair, Вы писали:
S>Я, кстати, говорил не про этот пример. А про пример, приведенный meowth, где при изменении одного OrderItem в память поднимается вся коллекция детей ордера для пересчёта total. О да, тут мы уверены в енфорсинге всех бизнес рулов. Ну, конечно, batch in LL рулит неимоверно. S>Это по сравнению с кодом вида update _order set amt = (select sum(amount) from orderItem oi where orderId = @orderID) where id = @orderId. Ага-ага. Нет, у меня определенно дефицит сарказма.
Что-то я не понял, каким ОРМ тулом мы делаем подобные действия? При чем тут модель? Прямой запрос к базе на чистом сиквеле делается в любой модели и к выбраной модели не относится вообще.
Z>>Я думал мы уже обсосали этот пример и я признал определенный недостаток рич модели: при написании кода в ней надо думать над тем, что достается из базы, хотя и некоторым кажется, что это необязательно. Мне это можно больше не доказывать и в каждом посте не упоминать об этом. Пожалей свое и мое время. S>Не понял — а о чём тогда вы хотите поговорить? Я не собираюсь спорить с тезисом "иногда, при осторожном использовании, рич модель сосёт не слишком сильно по сравнению с анемик". S>Я просто всё еще жду жызненного примера, где рич порвёт анемик на тряпки. А то получается, что супергуру рич модели приводят в её защиту примеры, которые заведомо чудовищно неэффективны. Еще раз: не как пример "наивного" кода. А как пример того, что пишет компетентный девелопер в рич модели. Кому вы хотите продать рич модель? С такой-то аргументацией?
Я где-то утверждал, что она рвет анемик на тряпки? Я утверждал, что она может стать проще для поддержки внесения изменений. Это сложно доказать. Я в свою очередь жду пример сценария, а не императивного кода, где рич модель не может быть эффективна.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Не надо себя убеждать в этом. G>>Во-первых Linq запрос на вытягивание данных получается короче, писать тупой код становится сложнее, так как надо больше писать. G>>Во-вторых когда начинаешь писать запросы оказывается что часть действий может быть выполнена в БД, с гораздо большей эффективностью, чем в приложении. Объем кода от этого неувеличивается, а зачастую уменьшается так как запросы более декларативны.
Z>Давай так, будем говорить за себя. Рич модель лично тебя делает настолько тупым, что ты начинаешь забывать, что БД эффективнее делает запросы?
Какой-то наезд не в тему
Z>>>Это такой прием демагогии, написать тупейший пример и потом ссылаться на него как на ключевой недостаток модели, рекомендую воздерживаться от постоянного его применения, чтобы дискуссия продолжала оставаться конструктивной. G>>Это не просто тупой пример. Это код, который вполне может быть написан с применением LL. G>>Примеры которые ты выдумываешь вряд ли будут когда-то написаны, так как они сложнее правильного варианта.
Z>Зато правильный вариант точно такой же как и линковский: Z>
Z> var q = s.CreateQuery(@"select distinct i.Product.Category.Name
Z> from Order o join o.OrderItems i
Z> where o.Date between :startDate and :endDate")
Z> .SetParameter("startDate", startDate)
Z> .SetParameter("endDate", endDate)
Z> .List<string>();
Z>
Ну и в какой класс модели ты этот запрос засунешь?
Если вся программа на таких запросах, то rich не остается.
Кроме того текстовые запросы таят те же проблемы, что и SQL.
Напрмер у тебя в куче запросов надо выбирать ордеры в диапазоне дат, в твоем случае каждый запрос придется дублировать выделенный кусок кода, или заниматься конкатенацией строк (прощай читаемость).
Z>А теперь напиши линковский запрос в случае, когда твоя анемик модель действительно анемик. Т.е. у объектов нет навигационные связи только в виде OrderId в OrderItem.
Зачем оно мне? Я представляю связи между данными так как мне удобно.
G>Ну и в какой класс модели ты этот запрос засунешь?
Это явно сервисный метод, OrderService, в модель засовываются только те методы которы изменяют данный класс или класс для которого данный является aggregation root. Для выборок — те методы для которых основным аргументом является this.
G>Если вся программа на таких запросах, то rich не остается.
А если не вся, то останется.
G>Кроме того текстовые запросы таят те же проблемы, что и SQL. G>Напрмер у тебя в куче запросов надо выбирать ордеры в диапазоне дат, в твоем случае каждый запрос придется дублировать выделенный кусок кода, или заниматься конкатенацией строк (прощай читаемость).
А альтернатива это linq? Ну так рекламируй linq, при чем тут модель?
Z>>А теперь напиши линковский запрос в случае, когда твоя анемик модель действительно анемик. Т.е. у объектов нет навигационные связи только в виде OrderId в OrderItem. G>Зачем оно мне? Я представляю связи между данными так как мне удобно.
Ну ты же заставляешь меня пихать всю логику в классы модели, а не туда где мне удобно, а?
Здравствуйте, Ziaw, Вы писали:
Z>Что-то я не понял, каким ОРМ тулом мы делаем подобные действия?
Адекватный light-weight ORM должен это делать. См. напр. http://blogs.msdn.com/mattwar/archive/2009/01/22/building-a-linq-iqueryable-provider-part-xiii-iqtoolkit-v-0-13.aspx
Z>При чем тут модель? Прямой запрос к базе на чистом сиквеле делается в любой модели и к выбраной модели не относится вообще.
Чистый сиквел не типобезопасен и крайне труден в приготовлении. Нас не интересует возможность исполнить в СУБД какую-то строку. Нас интересует возможность собрать нужный запрос из нескольких фрагментов. Ну, а рич здесь проезжает мимо кассы потому, что в ней невозможно корректно обновить кэш при выполнении таких вот "непрозрачных" запросов.
S>>Я просто всё еще жду жызненного примера, где рич порвёт анемик на тряпки. А то получается, что супергуру рич модели приводят в её защиту примеры, которые заведомо чудовищно неэффективны. Еще раз: не как пример "наивного" кода. А как пример того, что пишет компетентный девелопер в рич модели. Кому вы хотите продать рич модель? С такой-то аргументацией?
Z>Я где-то утверждал, что она рвет анемик на тряпки?
Нет. Но я же могу помечтать Z>Я утверждал, что она может стать проще для поддержки внесения изменений. Это сложно доказать.
Это очень просто доказать — достаточно привести пример, и тупо посчитать количество изменяемых строчек. Z>Я в свою очередь жду пример сценария, а не императивного кода, где рич модель не может быть эффективна.
Ну, я привёл пример сценария. Оказалось, что для него ричность модели использовать нельзя — потому что предложенное решение 1:1 такое же как анемик.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Если вся программа на таких запросах, то rich не остается. Z>А если не вся, то останется.
А смысл? Зачем размазывать БЛ по классам с разными обязаннстями?
G>>Кроме того текстовые запросы таят те же проблемы, что и SQL. G>>Напрмер у тебя в куче запросов надо выбирать ордеры в диапазоне дат, в твоем случае каждый запрос придется дублировать выделенный кусок кода, или заниматься конкатенацией строк (прощай читаемость). Z>А альтернатива это linq? Ну так рекламируй linq, при чем тут модель?
Есть такой паттерн — QueryObject. Основное его преимущество в том что запросы можно строить динамически, накладывая произвольные проекции, соединения и грппировки.
Linq — отличное средство для построения таких QueryObject_ов, в проверками типов во время компиляции и удобным маппингом результатов выборки.
Тем не менее он не является необходимым. В Entity Framework есть текстовый eSQL, на котором построены Query Objects. eSQL вполне позволяет делать все тоже самое, даже немного больше (текстовая генерация иногда удобнее).
Z>>>А теперь напиши линковский запрос в случае, когда твоя анемик модель действительно анемик. Т.е. у объектов нет навигационные связи только в виде OrderId в OrderItem. G>>Зачем оно мне? Я представляю связи между данными так как мне удобно. Z>Ну ты же заставляешь меня пихать всю логику в классы модели, а не туда где мне удобно, а?
Я не заставляю. Если не пихать всю логику в классы модели, то rich не останется.
Здравствуйте, gandjustas, Вы писали:
G>Есть такой паттерн — QueryObject. Основное его преимущество в том что запросы можно строить динамически, накладывая произвольные проекции, соединения и грппировки. G>Linq — отличное средство для построения таких QueryObject_ов, в проверками типов во время компиляции и удобным маппингом результатов выборки. G>Тем не менее он не является необходимым. В Entity Framework есть текстовый eSQL, на котором построены Query Objects. eSQL вполне позволяет делать все тоже самое, даже немного больше (текстовая генерация иногда удобнее).
Какое это отношение имеет к выбранной модели? Этот паттерн реализуется на уровне ОРМ, а не на уровне модели.
Z>>>>А теперь напиши линковский запрос в случае, когда твоя анемик модель действительно анемик. Т.е. у объектов нет навигационные связи только в виде OrderId в OrderItem. G>>>Зачем оно мне? Я представляю связи между данными так как мне удобно. Z>>Ну ты же заставляешь меня пихать всю логику в классы модели, а не туда где мне удобно, а? G>Я не заставляю. Если не пихать всю логику в классы модели, то rich не останется.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Есть такой паттерн — QueryObject. Основное его преимущество в том что запросы можно строить динамически, накладывая произвольные проекции, соединения и грппировки. G>>Linq — отличное средство для построения таких QueryObject_ов, в проверками типов во время компиляции и удобным маппингом результатов выборки. G>>Тем не менее он не является необходимым. В Entity Framework есть текстовый eSQL, на котором построены Query Objects. eSQL вполне позволяет делать все тоже самое, даже немного больше (текстовая генерация иногда удобнее).
Z>Какое это отношение имеет к выбранной модели? Этот паттерн реализуется на уровне ОРМ, а не на уровне модели.
Самое прямое: использование запросов, а не работу с объектами, навигационный доступ и LL порождает совершенно другой дизайн кода.
Именно об этом тут пытаются толковать.
Кстати именно поэтому в спорах anemic vs rich там мало примеров приводят. Отличия обыно глобальные, которые невозможно рассмотреть в паре десятков строчек, а в простых случаях код выглядит одинаково.
Здравствуйте, gandjustas, Вы писали:
G>Самое прямое: использование запросов, а не работу с объектами, навигационный доступ и LL порождает совершенно другой дизайн кода.
У тебя в модели и навигационный доступ и работа с объектами однако присутствует.
G>Именно об этом тут пытаются толковать. G>Кстати именно поэтому в спорах anemic vs rich там мало примеров приводят. Отличия обыно глобальные, которые невозможно рассмотреть в паре десятков строчек, а в простых случаях код выглядит одинаково.
Отличия как раз очень простые, пишут ли логику в классах модели. Может сама модель запрещать использовать себя не по правилам или для этого требуется дополнительный слой сервисов.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Самое прямое: использование запросов, а не работу с объектами, навигационный доступ и LL порождает совершенно другой дизайн кода. Z>У тебя в модели и навигационный доступ и работа с объектами однако присутствует.
Это только только удобный способ выражать связи.
Да и без LL навигационный доступ вполне может жить, только повсеместное его использование приводит к появлению монструозного кода.
G>>Именно об этом тут пытаются толковать. G>>Кстати именно поэтому в спорах anemic vs rich там мало примеров приводят. Отличия обыно глобальные, которые невозможно рассмотреть в паре десятков строчек, а в простых случаях код выглядит одинаково.
Z>Отличия как раз очень простые, пишут ли логику в классах модели. Может сама модель запрещать использовать себя не по правилам или для этого требуется дополнительный слой сервисов.
Эти "простые отличия" тянут за собой множество непростых.
