Re[47]: Anemic Domain Model vs Rich Domain Model
От: Ziaw Россия  
Дата: 02.06.09 09:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да и без LL навигационный доступ вполне может жить, только повсеместное его использование приводит к появлению монструозного кода.


Именно. А LL лишь раздвигает рамки использования.

G>>>Именно об этом тут пытаются толковать.

G>>>Кстати именно поэтому в спорах anemic vs rich там мало примеров приводят. Отличия обыно глобальные, которые невозможно рассмотреть в паре десятков строчек, а в простых случаях код выглядит одинаково.

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

G>Эти "простые отличия" тянут за собой множество непростых.

Тянут только для того, чтобы принести некие (небесплатные) удобства, поскольку в анемик ты привык обходиться без них в рич тоже сможешь себе это позволить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[48]: Anemic Domain Model vs Rich Domain Model
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.06.09 09:42
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, gandjustas, Вы писали:


G>>Да и без LL навигационный доступ вполне может жить, только повсеместное его использование приводит к появлению монструозного кода.

Z>Именно. А LL лишь раздвигает рамки использования.
Рамки использования тула — да. Вообще тул должен предоставлять все возможности.
Рамки применения навигационного доступа в anemic — нет.


G>>>>Именно об этом тут пытаются толковать.

G>>>>Кстати именно поэтому в спорах anemic vs rich там мало примеров приводят. Отличия обыно глобальные, которые невозможно рассмотреть в паре десятков строчек, а в простых случаях код выглядит одинаково.

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

G>>Эти "простые отличия" тянут за собой множество непростых.

Z>Тянут только для того, чтобы принести некие (небесплатные) удобства, поскольку в анемик ты привык обходиться без них в рич тоже сможешь себе это позволить.

Ок, пошли по N+1 кругу.
Какие удобства имеются ввиду?
Щас опять выяснится что удобств на самом деле и нет.
Re[39]: Anemic Domain Model vs Rich Domain Model
От: kvasya  
Дата: 03.06.09 05:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>


Не сочтите за наглость

Можете посоветовать какой-нибудь пример реализации (opensource) Anemic модели?
(Хочется посмотреть "как люди делают" и сравнить как делаю я)
adm
Re[40]: Anemic Domain Model vs Rich Domain Model
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 06:23
Оценка: 2 (1)
Здравствуйте, kvasya, Вы писали:
K>Можете посоветовать какой-нибудь пример реализации (opensource) Anemic модели?
K>(Хочется посмотреть "как люди делают" и сравнить как делаю я)
BLToolkit?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Anemic Domain Model vs Rich Domain Model
От: Константин Л. Франция  
Дата: 05.06.09 10:01
Оценка: -1
Здравствуйте, meowth, Вы писали:

[]

M>Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД?


Дело в том, что в anemic к этому готовы и это нормально. А в риче вы либо получите 100 копий классов для одного и того же объекта предметной области, либо получите один, но написанный так, что он внутри должен учитывать все эти варианты неполноты данных. И в итоге будет так, что половина его методов просто не будут работать. Чтобы они работали нуден контекст, который в anemic всегда есть, тк вы знаете какие данные у вас есть, вы же их только что выбрали

[]
Re[21]: Anemic Domain Model vs Rich Domain Model
От: meowth  
Дата: 05.06.09 11:30
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, meowth, Вы писали:


КЛ>[]


M>>Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД?


КЛ>Дело в том, что в anemic к этому готовы и это нормально.

К чему готовы-то? К тому, что данные попадают из БД в программу без запроса к БД?

КЛ>А в риче вы либо получите 100 копий классов для одного и того же объекта предметной области, либо получите один, но написанный так, что он внутри должен учитывать все эти варианты неполноты данных. И в итоге будет так, что половина его методов просто не будут работать.

ММ.. по-моему, вы сами счас придумали для rich model этот dirty hack, и начинаете укорять в нем rich. Попробуйте представить себе несколько окружений -- например, web-сессию, которая держит контекст на время обработки запроса.

КЛ>Чтобы они работали нуден контекст, который в anemic всегда есть, тк вы знаете какие данные у вас есть, вы же их только что выбрали

Не вижу, как это противоречит rich model или является ее недостатком или чем-то нереализуемым
Re[22]: Anemic Domain Model vs Rich Domain Model
От: Константин Л. Франция  
Дата: 05.06.09 13:09
Оценка:
Здравствуйте, meowth, Вы писали:

M>Здравствуйте, Константин Л., Вы писали:


КЛ>>Здравствуйте, meowth, Вы писали:


КЛ>>[]


M>>>Во-вторых, вы что-путаете. Что значит -- "с неполными данными"? В anemic как-то по-другому данные в коде оказываются, без запроса к БД?


КЛ>>Дело в том, что в anemic к этому готовы и это нормально.

M>К чему готовы-то? К тому, что данные попадают из БД в программу без запроса к БД?

К тому, что все что нам надо у нас есть, так как мы только что это взяли из базы.

КЛ>>А в риче вы либо получите 100 копий классов для одного и того же объекта предметной области, либо получите один, но написанный так, что он внутри должен учитывать все эти варианты неполноты данных. И в итоге будет так, что половина его методов просто не будут работать.

M>ММ.. по-моему, вы сами счас придумали для rich model этот dirty hack, и начинаете укорять в нем rich. Попробуйте представить себе несколько окружений -- например, web-сессию, которая держит контекст на время обработки запроса.

Я придумал dirty hack? Ditry hack это иметь рич, но в большинстве случаев пользоваться срезами

КЛ>>Чтобы они работали нуден контекст, который в anemic всегда есть, тк вы знаете какие данные у вас есть, вы же их только что выбрали

M>Не вижу, как это противоречит rich model или является ее недостатком или чем-то нереализуемым

Противоречит в том, что вы ничего не знаете о том, когда и какие данные вы взяли, чтобы сделать какую-то операцию
Re[23]: Anemic Domain Model vs Rich Domain Model
От: meowth  
Дата: 05.06.09 16:17
Оценка:
Здравствуйте, Константин Л., Вы писали:

..[Многа букафф]..

Не хочу я с вами спорить, извините Давайте будем априори считать, что в споре вы правы (*)
Любой инструмент имеет границы применимости. Так же для любого инструмента имеются best practices, которые позволяют выступить ему во всей красе. Поэтому не стоит объединять недостатки модели и недостатки ОРМ, а также следует "включать мозг", как пишет gandjustats, когда пишется код -- естественно, никто не станет глубоко бродить по графу объектов, надеясь на LL.
В чистом виде rich или anemic в моем опыте не применялся никогда (и не в моем тоже никогда не видел, кроме канонического ActiveRecord или Data Services), а, значит, проблемы одного обходились возможностями другого.
Мне кажется, тут спорить не о чем. Если я не прав -- см. (*)
Re[19]: Anemic Domain Model vs Rich Domain Model
От: Лобанов Игорь  
Дата: 06.06.09 15:34
Оценка:
Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Лобанов Игорь, Вы писали:


ЛИ>>Есть разные варианты:

ЛИ>>1) Самый простой: кэш локален на каждом узле, согласованность обеспечивается синхронной инвалидацией;
ЛИ>>2) Для кэша используются отдельные специализированные узлы. Это стандартное решение для создания высоконагруженных приложений на платформе LAMP+memcached;
ЛИ>>3) Самый сложный: данные в кэше автоматически реплицируются и балансируются между узлами, что обеспечивает высокую надёжность. Ключевые слова: consistent hashing, in-memory data grid, cache partitioning. Сейчас (по крайней мере в JEE) такое умеют только дорогие проприетарные продукты типа Oracle Coherence, но на подходе и open source альтернативы.

K>А вот теперь объясните мне пожалуйста, ради каких таких серьёзных и неоспоримых преимуществ стоит городить весь этот огород? Когда проблема элементарно решается reverse http proxy + proxy + клиентское кэширование — если мы говорим про веб (хотите узнать как — спросите у Синклера — он объяснит, если, конечно, его не заломает объяснять это в 1000001-й раз)...


О решении какой проблемы Вы говорите?

Я говорил о том, какими способами можно подружить кэш и кластеры.
Re[11]: Anemic Domain Model vs Rich Domain Model
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 07.06.09 04:44
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я знаю как системы кеширования запускать. Вопрос не в этом.

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

Что самое интересное, на высоких нагрузках в этот кэш уедет полбазы, а потом получается вообще патовая ситуация — одни и те же данные хранятся в двух разных местах К чему всё это?
[КУ] оккупировала армия.
Re[12]: Anemic Domain Model vs Rich Domain Model
От: meowth  
Дата: 07.06.09 08:31
Оценка:
Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, gandjustas, Вы писали:


G>>Я знаю как системы кеширования запускать. Вопрос не в этом.

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

K>Что самое интересное, на высоких нагрузках в этот кэш уедет полбазы, а потом получается вообще патовая ситуация — одни и те же данные хранятся в двух разных местах К чему всё это?


Толсто
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.