> ...
Иногда создается такое впечатление, что единственное отличие "толстой" модели от "тонкой" — это ленивая загрузка. Причем обсуждаемая в контексте клиента. Хотя в большинстве случаев клиент удаленный, и "ленивую" загрузку явно практически не использует, а использует ДТО. Хотя возможно есть решения, когда объекты передачи данных тоже используют отложенную загрузку, однако они из области частных решений.
Как мне кажется, единственное объективное удобство тонкой модели в том, что она естественным образом ложится на сервис-ориентированную архитектуру, более того, она специально разрабатывается для такой архитектуры. Это позволяет при желании сэкономить на написании выделенного (отдельного) фасада системы.
Здравствуйте, Sinclair, Вы писали:
S>... S>Проблема — в том, что обращение Order.Items прячет от клиента важную семантику.
S>К примеру, все коннекторы к СУБД, применяемые в дотнете, поддерживают асинхронную модель исполнения. Это означает, что умный клиентский код может запросить недостающие данные, и пока они готовятся, заниматься своими делами.
S>В применении к Order.Items это означает, что эта "инкапсуляция" вынуждает клиентский код выполнять ряд запросов последовательно, блокируясь на время ожидания. Что, естественно, ухудшает производительность.
S>Далее, у клиентского кода, который делает вызов Order.Items нет никакого способа сообщить инфраструктуре подробности своих пожеланий. Он не может отменить запрос, если он занял больше времени, чем ожидалось. Он не может внятно объяснить, важно ли ему обеспечить транзакционную целостность между Order и Items, или можно отдать текущее состояние Items, а не то, которое было в момент загрузки Order. Он не может объяснить, что уже однажды загружал Items для этого Order, и теперь ему нужно обновить их, причем только в том случае, если хоть что-то поменялось.
Если дела обстоят именно так, как Вы описываете, тогда действительно, делать Order.Items свойством — это ошибка проектирования.
S>Все эти полезные подробности, вытекающие из удаленного характера Items, скрыты за тупым геттером.
См. выше. Однако, рассмотрите также и ситуацию, когда Ордер.Айтемс — это именно свойство Ордер. С семантикой свойства. Ни один Айтем без заказа не существует. Удаляются они все вместе. Ну и так далее. Скажите, в таком случае отложенная загрузка — тоже плохо?
Кстати, почему это Вы говорите, что Items имеют "удаленный" характер? Отложенная загрузка ведь происходит на сервере приложения, а клиент получает уже сконструированные ДТО, в которых или есть заполненные Items, или нет никаких, и их нужно грузить отдельно.
S>Некоторые из них можно получить, подергав за неочевидные настройки какого-то контекста. Изучение этих неочевидных настроек и составляет квалификацию опытного разработчика под Full-blown ORM. При этом некоторые из возможностей вообще остаются неизвестными даже для самых продвинутых разработчиков — к примеру, асинхронная модель исполнения.
Преимущество ОРМ здесь в том, что он позволяет управлять способом, которым грузится коллекция Айтемов, что позволяет настраивать и оптимизировать уже после разработки, в процессе нагрузочного тестирования. Если окажется, что злая отложенная загрузка хоть и тормозит по определению, но не в критических местах, и работе не особо мешает, то оставляем все как есть, если же сильно уменьшает производительность — то можно начать заниматся настройкой — начиная от выключения отложенной загрузки для конкретного свойства, заканчивая загрузкой Order and all Items одним оптимизированным запросом.
S>Поэтому, продолжая твою терминологию, если клиентскому коду "насрать", то гарантированно получится "говно".
Ну тут не поспоришь
Здравствуйте, Sergey T., Вы писали:
ST>Если дела обстоят именно так, как Вы описываете, тогда действительно, делать Order.Items свойством — это ошибка проектирования.
S>>Все эти полезные подробности, вытекающие из удаленного характера Items, скрыты за тупым геттером. ST>См. выше. Однако, рассмотрите также и ситуацию, когда Ордер.Айтемс — это именно свойство Ордер. С семантикой свойства. Ни один Айтем без заказа не существует. Удаляются они все вместе. Ну и так далее. Скажите, в таком случае отложенная загрузка — тоже плохо?
Естественно. Совершенно неважно, что айтемы не могут жить без ордера.
Во-первых, это неправда — в топике Иван приводил, почему. В частности, менеджера поставок вообще не интересует, в каких заказах расположены айтемы.
С его точки зрения, айтемы принадлежат товару.
Во-вторых, каким образом подробности удаления айтомов оправдывают их отложенную загрузку?
ST>Кстати, почему это Вы говорите, что Items имеют "удаленный" характер?
Потому что расстояние от сервера приложений до СУБД на несколько порядков больше, чем до собственной памяти.
ST>Преимущество ОРМ здесь в том, что он позволяет управлять способом, которым грузится коллекция Айтемов, что позволяет настраивать и оптимизировать уже после разработки, в процессе нагрузочного тестирования. Если окажется, что злая отложенная загрузка хоть и тормозит по определению, но не в критических местах, и работе не особо мешает, то оставляем все как есть, если же сильно уменьшает производительность — то можно начать заниматся настройкой — начиная от выключения отложенной загрузки для конкретного свойства, заканчивая загрузкой Order and all Items одним оптимизированным запросом.
Еще раз поясняю простую мысль: зачем сначала портить производительность, а потом ее обратно улучшать "только если получится слишком плохо"?
Подход, в котором загрузка данных прописана явно, ничуть не менее компактен, чем подход со "скрытыми граблями". При этом есть масса дополнительных преимуществ.
S>>Поэтому, продолжая твою терминологию, если клиентскому коду "насрать", то гарантированно получится "говно". ST>Ну тут не поспоришь
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey T., Вы писали:
ST>Иногда создается такое впечатление, что единственное отличие "толстой" модели от "тонкой" — это ленивая загрузка.
Это происходит потому, что в качестве оппонентов тут же набегает толпа любителей разного рода ORM (которые практически все пляшут именно от жирной модели) и начинают рассказывать, что при наличии инструментария и так можно жить. А когда начинаешь разбираться как именно оно живет, тут и всплывает ленивая загрузка, в качестве костыля, который помогает обходить грабли ORM.
Если же ты конкретно про ВВ, то я вообще не понимаю о чем он.
ST>Причем обсуждаемая в контексте клиента. Хотя в большинстве случаев клиент удаленный, и "ленивую" загрузку явно практически не использует, а использует ДТО.
Вот, DTO — это второй костыль.
ST>Как мне кажется, единственное объективное удобство тонкой модели в том, что она естественным образом ложится на сервис-ориентированную архитектуру, более того, она специально разрабатывается для такой архитектуры.
Объективное удобство стройной модели в том, что она менее связна.
Здравствуйте, Sergey T., Вы писали:
>> ... ST>Иногда создается такое впечатление, что единственное отличие "толстой" модели от "тонкой" — это ленивая загрузка.
Создается. Но ведь с другой стороны — толстая модель ведь не обязывает нас использовать ленивую загрузку — независимо от того, как там оформлены связи между сущностями. Никто не мешает делать загрузку явно, и это будет по-прежнему "жирно".
Не говоря уж о том, что в некоторых случаях представление связанных сущностей через какое-нибудь св-во типа Items — например, у нас отношение многое-ко-многим — просто-напросто неразумно, независимо от модели.
ST>Причем обсуждаемая в контексте клиента. Хотя в большинстве случаев клиент удаленный, и "ленивую" загрузку явно практически не использует, а использует ДТО. Хотя возможно есть решения, когда объекты передачи данных тоже используют отложенную загрузку, однако они из области частных решений.
ST>Как мне кажется, единственное объективное удобство тонкой модели в том, что она естественным образом ложится на сервис-ориентированную архитектуру, более того, она специально разрабатывается для такой архитектуры. Это позволяет при желании сэкономить на написании выделенного (отдельного) фасада системы.
Я в общем-то не отрицаю преимуществ тонкой модели, собственно, возможность выделить сервисы очень часто бывает полезной. Да и сам во многих случаях предпочел бы толстой модели тонкую.
Меня возмущает критика толстой модели, приведенная в статье по ссылке. Критика — абсолютно несостоятельна. Какие бы там ни были наши предпочтения и как бы ни хотелось "защитить" EF, но выдавать утверждения в стиле, что толстая модель "все валит в кучу", предполагает смешивать разнородный код да еще так, что какая-то нибудь сериализация в ХМЛ будет тесно переплена с дата-аксесом, а уж алгоритмы поменять независимо от данных, как тут Синлер распыляется, это вообще анрыл — это по-моему просто неправильно. Да еще, извините, Фаулера тут поминать как "мальчика для битья".
Критика должна быть разумной. И критика конкретно NHibernate != киритка толстой модели вообще.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Но ведь с другой стороны — толстая модель ведь не обязывает нас использовать ленивую загрузку — независимо от того, как там оформлены связи между сущностями. Никто не мешает делать загрузку явно, и это будет по-прежнему "жирно".
Есть проблема. Если не использовать ленивую загрузку в жирной модели, то при обращении к одному объекту, в память поднимется вся база.
ВВ>Меня возмущает критика толстой модели, приведенная в статье по ссылке.
Есть курсы по управлению гневом.. )
ВВ> Критика — абсолютно несостоятельна.
Просто надо внимательно читать.
ВВ>но выдавать утверждения в стиле, что толстая модель "все валит в кучу",
Цитату можно?
ВВ> предполагает смешивать разнородный код да еще так, что какая-то нибудь сериализация в ХМЛ будет тесно переплена с дата-аксесом, а уж алгоритмы поменять независимо от данных, как тут Синлер распыляется, это вообще анрыл — это по-моему просто неправильно.
... ВВ>Какие бы там ни были наши предпочтения и как бы ни хотелось "защитить" EF, ВВ> И критика конкретно NHibernate != киритка толстой модели вообще.
- Иногда письма не доходят.
— Да, бывалыча пишешь письмо, получаешь ответ и понимаешь — не дошло письмо, не дошло.
ВВ>Критика должна быть разумной.
О! Истину глаголешь.
Здравствуйте, IB, Вы писали:
ВВ>>Но ведь с другой стороны — толстая модель ведь не обязывает нас использовать ленивую загрузку — независимо от того, как там оформлены связи между сущностями. Никто не мешает делать загрузку явно, и это будет по-прежнему "жирно". IB>Есть проблема. Если не использовать ленивую загрузку в жирной модели, то при обращении к одному объекту, в память поднимется вся база.
Кроме "грузить неявно через ленивую загрузку" и "грузить сразу все" других вариантов не видишь?
ВВ>>Меня возмущает критика толстой модели, приведенная в статье по ссылке. IB>Есть курсы по управлению гневом.. )
А я спокоен. Очень спокоен. Очень-очень спокоен. Ты что, утверждаешь, что я не спокоен?!
ВВ>> Критика — абсолютно несостоятельна. IB>Просто надо внимательно читать.
Я прочитал внимательно. А вот остальные участники дискуссии, как мне кажется, нет.
ВВ>>но выдавать утверждения в стиле, что толстая модель "все валит в кучу", IB>Цитату можно?
Например:
Именно по этому, привязывать определенным данным какое-либо поведение посредством "жирной" модели — дурная затея. Во-первых, меняя в десятый раз поведение данные нужно оставлять неизменными. Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое и не накручивать поверх старого, при этом стараясь оставить данные по прежнему неизменными.
...
Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД — то, когда понадобится хранить те же данные в кеше, вьюстейте, сессии или сериализовать еще куда-нибудь, придется либо добавить еще один метод .Save(), то есть, модифицировать существующий класс, вместо того, чтобы просто добавить новый, либо размещать новый Save() в другом классе, не понятно по какой причине ставя Save() в базу данных в привилегированное положение по отношению к другим Save-ам.
...
На первый взгляд, кажется что в "жирнной" модели код хорошо инкапсулирован, но это не так. На самом деле, как это ни странно, лучше всего код инкапсулруется именно "стройной" модели. Инкапсуляция призвана скрывать детали реализации за публичным контрактом. Однако, в случае "жирной" модели детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса. Этот никак, по смыслу, не связанный между собой функционал, вполне может начать влиять друг на друга при неаккуратной реализации, а компилятор никак не сможет это дело проконтролировать.
И там еще много такого. Почитайте.
ВВ>> предполагает смешивать разнородный код да еще так, что какая-то нибудь сериализация в ХМЛ будет тесно переплена с дата-аксесом, а уж алгоритмы поменять независимо от данных, как тут Синлер распыляется, это вообще анрыл — это по-моему просто неправильно. IB>... ВВ>>Какие бы там ни были наши предпочтения и как бы ни хотелось "защитить" EF, ВВ>> И критика конкретно NHibernate != киритка толстой модели вообще. IB>
IB>- Иногда письма не доходят.
IB>- Да, бывалыча пишешь письмо, получаешь ответ и понимаешь — не дошло письмо, не дошло.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Кроме "грузить неявно через ленивую загрузку" и "грузить сразу все" других вариантов не видишь?
Давай другие.
ВВ>Я прочитал внимательно. А вот остальные участники дискуссии, как мне кажется, нет.
Ага, один ты в белом...
ВВ>>>но выдавать утверждения в стиле, что толстая модель "все валит в кучу", IB>>Цитату можно?
ВВ>Например:
Во первых, и где тут про то, что "толстая модель все валит в кучу"? То есть по сути так оно и есть, но конкретно этой фразы я нигде не говорил.
А во-вторых, что именно из процитированного не устраивает?
ВВ>И там еще много такого. Почитайте.
Я прекрасно помню, что писал.
ВВ>Если нечего сказать, то лучше и не говорить.
О! Заметь, это не я предложил.
Здравствуйте, IB, Вы писали:
ВВ>>Кроме "грузить неявно через ленивую загрузку" и "грузить сразу все" других вариантов не видишь? IB>Давай другие.
1) Грузить явно по требованию
2) Проектировать граф иначе (вкорячивать св-во ChildItems — это далеко не всегда в стиле ООП)
ВВ>>Я прочитал внимательно. А вот остальные участники дискуссии, как мне кажется, нет. IB>Ага, один ты в белом...
На пару с Фаулером.
ВВ>>>>но выдавать утверждения в стиле, что толстая модель "все валит в кучу", IB>>>Цитату можно?
ВВ>>Например: IB>Во первых, и где тут про то, что "толстая модель все валит в кучу"? То есть по сути так оно и есть, но конкретно этой фразы я нигде не говорил.
Цитирую по второму кругу:
1) "добавляя новое поведение, надо его просто добавлять, а не менять старое и не накручивать поверх старого"
2) "когда понадобится хранить те же данные в кеше, вьюстейте, сессии или сериализовать еще куда-нибудь, придется либо добавить еще один метод .Save(), то есть, модифицировать существующий класс"
3) "в случае "жирной" модели детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса. Этот никак, по смыслу, не связанный между собой функционал, вполне может начать влиять друг на друга при неаккуратной реализации"
Менять старое поведение ради добавления нового, писать новый Сейв внутри объекта для поддержки сериализации, детали реализации дата-аксеса "никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД" — это все, конечно же, совершенно не говорит о том, что у нас все свалено в одну кучу.
IB>А во-вторых, что именно из процитированного не устраивает?
Все.
ВВ>>И там еще много такого. Почитайте. IB>Я прекрасно помню, что писал.
Ага, вот где собака-то порылась
ВВ>>Если нечего сказать, то лучше и не говорить. IB>О! Заметь, это не я предложил.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>1) Грузить явно по требованию
И иметь объекты с наполовину не заполненными данными?
ВВ>2) Проектировать граф иначе (вкорячивать св-во ChildItems — это далеко не всегда в стиле ООП)
Об этом и речь.
ВВ>На пару с Фаулером.
Это вряд ли.
ВВ>Цитирую по второму кругу:
Отвечаю по второму кругу. Где конкретно в этих цитатах фраза "жирная модкль все валит в кучу"? Что конкретно неустраивает в процитированном?
ВВ>Все.
Твои проблемы.
ВВ>Тяжело воспринимаем критику, товарищ.
Критику я воспринимаю нормально, а вот агрессивный поток сознания без внятной мысли — не воспринимаю вообще.
Здравствуйте, IB, Вы писали:
ВВ>>1) Грузить явно по требованию IB>И иметь объекты с наполовину не заполненными данными?
Проектируем граф иначе, и таких проблем не будет.
ВВ>>2) Проектировать граф иначе (вкорячивать св-во ChildItems — это далеко не всегда в стиле ООП) IB>Об этом и речь.
Нет, речь о том, что жирная модель каким-то боком приравнивается к необходимости всегда иметь ленивый ChildItems.
Жирная модель — это ОО-модель. Она ни к чему кроме ОО не приравнивается.
ВВ>>Цитирую по второму кругу: IB>Отвечаю по второму кругу. Где конкретно в этих цитатах фраза "жирная модкль все валит в кучу"? Что конкретно неустраивает в процитированном?
Если нравится играть в дурачка и делать вид, что не понимаешь, что сам же писал:
детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса
и что
не связанный между собой функционал, вполне может начать влиять друг на друга
то ради бога.
Ждем новых статей. Пишите еще.
ВВ>>Все. IB>Твои проблемы.
Нет, ты не прав. Это не мои проблемы. Это проблемы написавшего, раз у него такое превратное понимание технологии. И неумение спорить, к сожалению.
ВВ>>Тяжело воспринимаем критику, товарищ. IB>Критику я воспринимаю нормально, а вот агрессивный поток сознания без внятной мысли — не воспринимаю вообще.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Проектируем граф иначе, и таких проблем не будет.
Об этом и речь. Надо проектировать как в стройной модели.
ВВ>Нет, речь о том, что жирная модель каким-то боком приравнивается к необходимости всегда иметь ленивый ChildItems.
Смотришь в книгу — видишь фигу. В жирной модели есть ChildItems, а уж ленивый ли он — сами разбирайтесь.
ВВ>Жирная модель — это ОО-модель.
Что такое ОО-модель?
ВВ>детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса ВВ>и что ВВ>не связанный между собой функционал, вполне может начать влиять друг на друга
И с чем из этого ты не согласен?
ВВ>Ждем новых статей. Пишите еще.
Обязательно..
ВВ> Это проблемы написавшего, раз у него такое превратное понимание технологии.
У писавшего очень правильное понимание технологии. Проблемы у тех, кто влезает не разобравшись в том, что написано.
ВВ>И неумение спорить, к сожалению.
Было бы с чем.
ВВ>Письма, видимо, действительно не доходят.
Писать пробовали?
Здравствуйте, IB, Вы писали:
ВВ>>Проектируем граф иначе, и таких проблем не будет. IB>Об этом и речь. Надо проектировать как в стройной модели.
Правильный дизайн — не прерогатива стройной модели.
ВВ>>Нет, речь о том, что жирная модель каким-то боком приравнивается к необходимости всегда иметь ленивый ChildItems. IB>Смотришь в книгу — видишь фигу.
Потому что кроме "фиги" в книге ничего нет.
IB>В жирной модели есть ChildItems, а уж ленивый ли он — сами разбирайтесь.
В жирной модели нет ChildItems. Она есть в воспаленном мозгу разработчика. Жирная модель — это объектно-ориентированная модель, не больше и не меньше. И композиция не единственный способ построения модели.
ВВ>>детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса ВВ>>и что ВВ>>не связанный между собой функционал, вполне может начать влиять друг на друга IB>И с чем из этого ты не согласен?
Один только момент я не допонял. Как по мне тема Rich vs Anemic Domain Model к материалу зря привязана. Отсюда и критика про смешинвание разных тем в кучу.
Rich vs Anemic Domain Model подразумевает именно наличие/отсутствие большого количества логики в классах с данными. То есть Rich DM подразумевает отсутствии Service как слоя инкапсулирующего бизнес логику.
Вторая же тема именно в способе организации модели данных, которые либо сильно связаны, держа ссылку друг на друга, либо связаны слабо на уровне базы, без сильных связей в классах модели данных.
По-моему темы перпендикулярны, так как я легко себе могу представить все четыре комбинации этих пар.
Слабо связанные данные с логикой
Слабо связанные без логики
Сильно связанные данные с логикой
Сильно связанные без логики
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса ВВ>>>и что ВВ>>>не связанный между собой функционал, вполне может начать влиять друг на друга IB>>И с чем из этого ты не согласен?
ВВ>Со смыслом.
Я так понимаю — IB пытается (ну ладно не особо пытается ) получить от вас какие-то детали возражений. Он очевидно не хочет рассыпаться в объяснениях, почему он считает выделенное правильным. Но если вы пытаетесь от него чего-то добиться — почему бы вам не привести больше деталей в своих рассуждениях, почему вы не согласны с выделенным.
Здравствуйте, IB, Вы писали:
IB>Это происходит потому, что в качестве оппонентов тут же набегает толпа любителей разного рода ORM (которые практически все пляшут именно от жирной модели) и начинают рассказывать, что при наличии инструментария и так можно жить. А когда начинаешь разбираться как именно оно живет, тут и всплывает ленивая загрузка, в качестве костыля, который помогает обходить грабли ORM.
Ну, почему сразу толпа. Я и набегаю. Тема интересная, есть над чем задуматся. Но при этом никто не запрещает разрывать модель и отказатся от ленивой загрузки используя все тот же ORM. И даже комбинировать оба варианта сильной и слабой связанности данных.
Здравствуйте, Blazkowicz, Вы писали:
B> Но при этом никто не запрещает разрывать модель и отказатся от ленивой загрузки используя все тот же ORM.
Да не мешает, конечно.. Но обычно этого не делают, так как во всех примерах работы с ORM приводится именно жирная модель в самом ее плохом проявлении.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Правильный дизайн — не прерогатива стройной модели.
Да, наверное стоит переформулировать — "один из признаков правильного дизайна — стройная модель", вот так будет правильно.
ВВ>Потому что кроме "фиги" в книге ничего нет.
Пока не разберешься — и не будет..
ВВ>В жирной модели нет ChildItems.
Формально нет, а по факту — есть.
ВВ> Жирная модель — это объектно-ориентированная модель, не больше и не меньше.
Да, это кривая объектно-ориентированная модель.
Я, кстати, так и не услышал от тебя, что же такое — объектно-ориентированная модель.
ВВ>Со смыслом.
Твои проблемы...
Здравствуйте, Blazkowicz, Вы писали:
B>Rich vs Anemic Domain Model подразумевает именно наличие/отсутствие большого количества логики в классах с данными. То есть Rich DM подразумевает отсутствии Service как слоя инкапсулирующего бизнес логику. B>Вторая же тема именно в способе организации модели данных, которые либо сильно связаны, держа ссылку друг на друга, либо связаны слабо на уровне базы, без сильных связей в классах модели данных.
Мы уже победили, просто это еще не так заметно...
Я и набегаю. Тема интересная, есть над чем задуматся. Но при этом никто не запрещает разрывать модель и отказатся от ленивой загрузки используя все тот же ORM. И даже комбинировать оба варианта сильной и слабой связанности данных.
