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

MC>Не знаю, как вы гуглите, но по запросу SRP в гугле — первая же ссылка — http://en.wikipedia.org/wiki/Single_responsibility_principle

Я на русском искал, английкий смысл может до меня дойти искаженным или вообще не дойти когда речь о таких абстрактных вещах.
Учу, учу английский

MC>С PI в гугле посложнее, но в общем это Persistence Ignorance, подход при котором слой бизнес логики и модель предметной области не знают ничего о том где и в каком виде данные сохраняются, читаются и как это происходит. Т.е. из бизнес логики исключается код, отвечающий за непосредственное сохранение/чтение данных и все нюансы с этим связанные.
MC>Persistence Ignorance подход способствует:
MC>1) вышеупомянутому SRP
MC>2) снижению coupling (все время забываю как лучше на русский перевести и чтобы никто не перепутал с cohesion)
MC>3) упрощению тестирования кода (улучшению тестируемости)
MC>4) повторному использованию
MC>5) лучшему структурированию и разделению кода по функциональности (separation of concerns, что в общем-то тоже можно отнести к SRP)

Спасибо, метод Save() в объектах никогда не понимал и что термин специальный есть не знал.

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

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

G>>Все равно надо как-то объясниить инфраструктуре когда получать объекты и когда сохранять изменения.
M>Какая-то философия получается. Выпил, поговорил с инфраструктурой, объяснил, где получать объекты, как сохранять.

M>>>Третье то, что коду бизнес-логики абсолюьно пофиг, что данные лежат где-то в БД. Их доставкой занимается инфраструктура и 1 (один сервис), называемый репозиторием. Причем это делается в режиме push, т.е. бизнес-логике вообще не надо никуда обращаться.
G>>Пример кода в студию. Даже интересно как такое выгялдит.
M>Будет вам код, будет

G>>А причем тут repository? Вот есть у нас объекта заказа. У него очевидно нету поведения.
M>Не передергивайте. Ваши "очевидно" очевидны только вам, видимо, даже с контрпримерами.
Это примерно как на лекциях в универе. Иногда то что "очевидно" становится понятно только после экзамена.

G>>Кто будет заниматтся созданием заказа?
M>Зависит от конкретного приложения; скорее всего, ordering facade.
Ну или ordering service А если еще у самого order нету поведения, то 100% anemic модель получается.


G>>>>Доказательством является саом наличие persistance инфрастуктуры с Identity map, Unit of work и прочими паттернами.
M>>>Не спорю. Но я не хочу работать с ними как с plain data, поэтому и есть эта инфраструктура.
G>>Инфраструктура пытается скрыть факт, что это данные, а не объекты. Причем очень несупешно. Особенно это заметно при множестве параллельных операций.
M>Покажите, как это заметно.
В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?


G>>>>Пока еще никому не удалось изобрести БД, которая отдает объекты (имеенно объекты, а не копию данных) с ссылочной эквивалентностью и без необходмости дополнительного преобразование, и чтобы при этом не было необходимости явно сохранять изменения.
M>>>В Smalltalk загляните -- там это есть.
G>>Ссылку?
M>Легко. Самое доступное изложение -- тут. Прочтите про squeak. http://habrahabr.ru/blogs/programming/55797/

G>>Ну как работает приведите пример требований и решение с помощью DDD.
G>>А потом разберем посмотрим как оно будет в anemic и ответим на несколкьо "что если", чтобы оценить расширяемостиь решения.
M>Предлагаю начать вам -- чтобы я мог ориентироваться по требованиям. А то потом опять будет -- то report calculator в domain не может быть, то кэш слишком большой и не устраивает.
Надо подумать.

M>Особенности db4o и то, что она может предложить, следует обсуждать в отдельном топике. Не уводите тему разговора. Вы просили ссылку, я привел, вы с ней согласились. То, что вы такое тоже можете реализовать (медаль вам, ту самую, кстате ) -- это оффтоп. Оффтоп -- в оффтопку.
Так по сути нету ничего принципиального в db4o, только другой способ представления данных и schemaless. Data!=Objects остается.

G>>Какому объекту предметной области соовествует report calculator или statistics? А состояние у этого объекта какое? Какими либо персистными даннми н заведует? как domain expert понимает что это за объект?
M>Никакому, я же сказал -- это синтетический объект, который введен, чтобы процесс построения отчета был более доступен для понимания. Он заведует данными о статистике обращений в БД по некоторому профилю. Что-то типа Builder в GoF. Так как статистика строится за период наблюдения, он представляет эти данные -- историю выборок.
Ну типичный сервис.

M>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
И у вас на таком начинает база загибатся?

M>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
Кеш — следствие. Причина в куче неконтроллируемых запросов, вызванных LL.

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

G>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
Зависит от запроса.

M>>Особенности db4o и то, что она может предложить, следует обсуждать в отдельном топике. Не уводите тему разговора. Вы просили ссылку, я привел, вы с ней согласились. То, что вы такое тоже можете реализовать (медаль вам, ту самую, кстате ) -- это оффтоп. Оффтоп -- в оффтопку.
G>Так по сути нету ничего принципиального в db4o, только другой способ представления данных и schemaless. Data!=Objects остается.
Разве я утверждал, что plain data == object? Я только говорил, что инфраструктура помогает поддерживать эту иллюзию.

G>>>Какому объекту предметной области соовествует report calculator или statistics? А состояние у этого объекта какое? Какими либо персистными даннми н заведует? как domain expert понимает что это за объект?
M>>Никакому, я же сказал -- это синтетический объект, который введен, чтобы процесс построения отчета был более доступен для понимания. Он заведует данными о статистике обращений в БД по некоторому профилю. Что-то типа Builder в GoF. Так как статистика строится за период наблюдения, он представляет эти данные -- историю выборок.
G>Ну типичный сервис.
Все может быть. Только я не знаю что такое сервис. Потому что история выборок -- такой же объект домена.

M>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>И у вас на таком начинает база загибатся?
Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.

M>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.

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


G>>>>Какому объекту предметной области соовествует report calculator или statistics? А состояние у этого объекта какое? Какими либо персистными даннми н заведует? как domain expert понимает что это за объект?
M>>>Никакому, я же сказал -- это синтетический объект, который введен, чтобы процесс построения отчета был более доступен для понимания. Он заведует данными о статистике обращений в БД по некоторому профилю. Что-то типа Builder в GoF. Так как статистика строится за период наблюдения, он представляет эти данные -- историю выборок.
G>>Ну типичный сервис.
M>Все может быть. Только я не знаю что такое сервис. Потому что история выборок -- такой же объект домена.

M>>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>>И у вас на таком начинает база загибатся?
M>Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.
Всего 600, причем statefull? А запросов в секунду сколько?

M>>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
M>LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.
А не проще не иметь таких проблем вообще?

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

MC>2) снижению coupling (все время забываю как лучше на русский перевести и чтобы никто не перепутал с cohesion)
Лучше не переводить. Хотя наиболее частоупотребимое "связность".

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

M>>>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>>>И у вас на таком начинает база загибатся?
M>>Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.
G>Всего 600, причем statefull? А запросов в секунду сколько?

Слишком многозначный термин -- запросов в секунду.
Давайте расчитаем в жестком режиме всякие запросы для 1го пользователя. Итак, различных запросов в секунду от толстого клиента пользователя -- 0.2 (будем считать вместе с heart-beat клиента). Один запрос -- это от 10 до 100 первичных выборок (зависит от данных), или ~2 — 20 первичных выборок в секунду. За счет кеша (cache hit ~0.9) это трансформируется в ~0.2 — 2 SQL Trans/секунду в БД на пользователя.

Для всех одновременно работающих пользователей это получается (0.2 -- 2) * 600 = (120 — 1200) SQL/сек на БД. Ну, 1200 SQL Trans/cек -- это пик, конечно, потому что пользователи редко долбят все сразу без остановки , но > 120 T/s бывает очень часто.

M>>>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
M>>LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.
G>А не проще не иметь таких проблем вообще?


Воббще без проблем оно конечно было бы лучше всего (:

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

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

M>>>>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>>>>И у вас на таком начинает база загибатся?
M>>>Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.
G>>Всего 600, причем statefull? А запросов в секунду сколько?

M>Слишком многозначный термин -- запросов в секунду.
M>Давайте расчитаем в жестком режиме всякие запросы для 1го пользователя. Итак, различных запросов в секунду от толстого клиента пользователя -- 0.2 (будем считать вместе с heart-beat клиента). Один запрос -- это от 10 до 100 первичных выборок (зависит от данных), или ~2 — 20 первичных выборок в секунду. За счет кеша (cache hit ~0.9) это трансформируется в ~0.2 — 2 SQL Trans/секунду в БД на пользователя.

M>Для всех одновременно работающих пользователей это получается (0.2 -- 2) * 600 = (120 — 1200) SQL/сек на БД. Ну, 1200 SQL Trans/cек -- это пик, конечно, потому что пользователи редко долбят все сразу без остановки , но > 120 T/s бывает очень часто.

не такая уж и зверская нагрузка чтобы кластер и распределенный кеш поднимать.
В принципе прикрутив кеширование по last-modified готовых объектов на клиенте и сервере, отказавшись от LL и собрав правльные joinы и проекции можно и на одном сервере это держать.
А если еще и справочные данные персистить на клиенте, то можно очень сильно разгрузить сервер.
Только при таком объеме базы вся аналитика должна делаться через OLAP с большим временем кеширования.

M>>>>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>>>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
M>>>LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.
G>>А не проще не иметь таких проблем вообще?
M>
M>
M>Воббще без проблем оно конечно было бы лучше всего (:
Так вам это и предлагают, а вы отказываетесь.

Я так понял что некоторых rich привлеккает своей прямолинейностью: пообщались с domain expert — нарисовали domain model. надо кудато поместить логику — прямо в объект с данными. нужны связанные данные — есть LL, все вытянет. Медленно тянет — используем навороченный кеш итп.
Anemic заставляет думать на каждом этапе: какую модель данных создать? Какие данные загружать для данной опрации? Как кеширование данных сделать? Как группировать методы в сервисы чтобы никто не запустался?

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

G>Я так понял что некоторых rich привлеккает своей прямолинейностью: пообщались с domain expert — нарисовали domain model. надо кудато поместить логику — прямо в объект с данными. нужны связанные данные — есть LL, все вытянет. Медленно тянет — используем навороченный кеш итп.
G>Anemic заставляет думать на каждом этапе: какую модель данных создать? Какие данные загружать для данной опрации? Как кеширование данных сделать? Как группировать методы в сервисы чтобы никто не запустался?

А не мог бы ты как нибудь написать тестовое приложение в стиле anemic? Ну чисто customer + order + orderline к примеру в winforms. Во-первых было бы многим полезно, во-вторых можно было бы уже его исопльзовать для обсуждения, приведения примеров кода и т.д.

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

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

G>>Я так понял что некоторых rich привлеккает своей прямолинейностью: пообщались с domain expert — нарисовали domain model. надо кудато поместить логику — прямо в объект с данными. нужны связанные данные — есть LL, все вытянет. Медленно тянет — используем навороченный кеш итп.
G>>Anemic заставляет думать на каждом этапе: какую модель данных создать? Какие данные загружать для данной опрации? Как кеширование данных сделать? Как группировать методы в сервисы чтобы никто не запустался?

MC>А не мог бы ты как нибудь написать тестовое приложение в стиле anemic? Ну чисто customer + order + orderline к примеру в winforms. Во-первых было бы многим полезно, во-вторых можно было бы уже его исопльзовать для обсуждения, приведения примеров кода и т.д.
Хотел бы, но пока времени нету. Кроме того делать что-то очень простое не хотелось бы, непоказательно будет.
Вероятнее всего пример будет на ASP.NET MVC. Писать MVP для winforms ломает — многословно получается. Потом может на wpf сделаю.

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

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

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

M>>>>>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>>>>>И у вас на таком начинает база загибатся?
M>>>>Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.
G>>>Всего 600, причем statefull? А запросов в секунду сколько?

M>>Слишком многозначный термин -- запросов в секунду.
M>>Давайте расчитаем в жестком режиме всякие запросы для 1го пользователя. Итак, различных запросов в секунду от толстого клиента пользователя -- 0.2 (будем считать вместе с heart-beat клиента). Один запрос -- это от 10 до 100 первичных выборок (зависит от данных), или ~2 — 20 первичных выборок в секунду. За счет кеша (cache hit ~0.9) это трансформируется в ~0.2 — 2 SQL Trans/секунду в БД на пользователя.

M>>Для всех одновременно работающих пользователей это получается (0.2 -- 2) * 600 = (120 — 1200) SQL/сек на БД. Ну, 1200 SQL Trans/cек -- это пик, конечно, потому что пользователи редко долбят все сразу без остановки , но > 120 T/s бывает очень часто.

G>не такая уж и зверская нагрузка чтобы кластер и распределенный кеш поднимать.
У меня не БД в кластере, у меня сервера приложений, а сервер БД -- 1. И распределенный кеш нужен именно поэтому -- чтобы не держать общие данные в кеше на каждом узле и чтобы не париться с настройкой инвалидации данных.

G>В принципе прикрутив кеширование по last-modified готовых объектов на клиенте и сервере, отказавшись от LL и собрав правльные joinы и проекции можно и на одном сервере это держать.
Я не хочу писать это руками -- нашей маленькой команде и так хватает дел. Стоимость решения будет в разы больше. Кроме того, наша модель меняется достаточно часто.
А так это уже все есть в инфраструктуре.

G>А если еще и справочные данные персистить на клиенте, то можно очень сильно разгрузить сервер.
G>Только при таком объеме базы вся аналитика должна делаться через OLAP с большим временем кеширования.
M>>>>>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>>>>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
M>>>>LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.
G>>>А не проще не иметь таких проблем вообще?
M>>
M>>
M>>Воббще без проблем оно конечно было бы лучше всего (:
G>Так вам это и предлагают, а вы отказываетесь.

G>Я так понял что некоторых rich привлеккает своей прямолинейностью: пообщались с domain expert — нарисовали domain model. надо кудато поместить логику — прямо в объект с данными. нужны связанные данные — есть LL, все вытянет. Медленно тянет — используем навороченный кеш итп.
G>Anemic заставляет думать на каждом этапе: какую модель данных создать? Какие данные загружать для данной опрации? Как кеширование данных сделать? Как группировать методы в сервисы чтобы никто не запустался?
Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.

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

MC>>А не мог бы ты как нибудь написать тестовое приложение в стиле anemic? Ну чисто customer + order + orderline к примеру в winforms. Во-первых было бы многим полезно, во-вторых можно было бы уже его исопльзовать для обсуждения, приведения примеров кода и т.д.
G>Хотел бы, но пока времени нету. Кроме того делать что-то очень простое не хотелось бы, непоказательно будет.
Дык можно набросать за пару часиков основу, а потом уже постепенно ее развивать чтобы становилось все более и более показательнее. К примеру спросил потом кто-то на форуме "а вот как сделать то-то?" — ты взял и добавил это для примера в свое приложение уже по быстрому.

G>Вероятнее всего пример будет на ASP.NET MVC. Писать MVP для winforms ломает — многословно получается. Потом может на wpf сделаю.
Имхо winforms было бы проще для понимания и показательнее... А насчет необходимости MVP.. ну не буду холивар поднимать

Вообще я думаю, что все эти споры потому что у каждого человека больше опыта в чем-то одном. Кто-то годами пишет в стиле rich и уже знает как решать все основные задачи и проблемы, но не очень хорошо знает как решать задачи и проблемы встающие при использовании anemic модели. Другой наоборот — годами пишет anemic, а опыта с rich моделью все-таки немного недостаточно, чтобы быть способным эффективно решать имеющиеся там проблемы. Вот они и начинают спорить друг с другом. В общем-то это почти как и любой спор — из-за того что люди не могут полностью понимать как мыслит, понимает и что и как делает другой человек. Если бы такое понимание вдруг пришло, то думаю что и споры бы сильно уменьшились, и пришло бы понимание что можно без проблем делать и так и так.

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

MC>Вообще я думаю, что все эти споры потому что у каждого человека больше опыта в чем-то одном. Кто-то годами пишет в стиле rich и уже знает как решать все основные задачи и проблемы, но не очень хорошо знает как решать задачи и проблемы встающие при использовании anemic модели. Другой наоборот — годами пишет anemic, а опыта с rich моделью все-таки немного недостаточно, чтобы быть способным эффективно решать имеющиеся там проблемы.

У нас тут маленькая проблемка, у нас тут есть человек кторый считает что очень круто знает и то и другое.

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

G>>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
M>Зависит от запроса.

А разве нельзя Equals() переопределить, чтобы было как надо?

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

G>>>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
M>>Зависит от запроса.

O> А разве нельзя Equals() переопределить, чтобы было как надо?

Тут видимо имеется в виду что получаются разные instance'ы объектов, а иногда нужно чтобы был только один instance, типа как бы глобальный IdentityMap.

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

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

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

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

M>>>>>>>Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
G>>>>>>И у вас на таком начинает база загибатся?
M>>>>>Угу. У нас 600 statefull пользователей онлайн сидят, работают. Работают -- это значит "общие данные". Если бы не было кеша, запросов было бы за сотню.
G>>>>Всего 600, причем statefull? А запросов в секунду сколько?

M>>>Слишком многозначный термин -- запросов в секунду.
M>>>Давайте расчитаем в жестком режиме всякие запросы для 1го пользователя. Итак, различных запросов в секунду от толстого клиента пользователя -- 0.2 (будем считать вместе с heart-beat клиента). Один запрос -- это от 10 до 100 первичных выборок (зависит от данных), или ~2 — 20 первичных выборок в секунду. За счет кеша (cache hit ~0.9) это трансформируется в ~0.2 — 2 SQL Trans/секунду в БД на пользователя.

M>>>Для всех одновременно работающих пользователей это получается (0.2 -- 2) * 600 = (120 — 1200) SQL/сек на БД. Ну, 1200 SQL Trans/cек -- это пик, конечно, потому что пользователи редко долбят все сразу без остановки , но > 120 T/s бывает очень часто.

G>>не такая уж и зверская нагрузка чтобы кластер и распределенный кеш поднимать.
M>У меня не БД в кластере, у меня сервера приложений, а сервер БД -- 1.
Это понятно. При распределенной БД были бы совершенно другие проблемы.

M>И распределенный кеш нужен именно поэтому -- чтобы не держать общие данные в кеше на каждом узле и чтобы не париться с настройкой инвалидации данных.
Ну это ему скорости не добавляет.


G>>В принципе прикрутив кеширование по last-modified готовых объектов на клиенте и сервере, отказавшись от LL и собрав правльные joinы и проекции можно и на одном сервере это держать.
M>Я не хочу писать это руками -- нашей маленькой команде и так хватает дел. Стоимость решения будет в разы больше. Кроме того, наша модель меняется достаточно часто.
M>А так это уже все есть в инфраструктуре.
"Этого" ни в одной инфраструктуре. Подходов к кешированию по last-modified может быть много, и зависят они от сценариев использования данных.
Зато такое кеширование является самым эффективным.

G>>А если еще и справочные данные персистить на клиенте, то можно очень сильно разгрузить сервер.
G>>Только при таком объеме базы вся аналитика должна делаться через OLAP с большим временем кеширования.
M>>>>>>>По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>>>>>Кеш — следствие. Причина в куче неконтролируемых запросов, вызванных LL.
M>>>>>LL -- это только принцип, как он реализован в конкретном инструменте -- другой вопрос. Если ваша инфраструктура не позволяет его контролировать в достаточной степени, то это плохо. Mike Chaliy вам тоже говорил, что все проблемы rich они заруливают в том числе грамотным тулингом -- выбором инструментов.
G>>>>А не проще не иметь таких проблем вообще?
M>>>
M>>>
M>>>Воббще без проблем оно конечно было бы лучше всего (:
G>>Так вам это и предлагают, а вы отказываетесь.

G>>Я так понял что некоторых rich привлеккает своей прямолинейностью: пообщались с domain expert — нарисовали domain model. надо кудато поместить логику — прямо в объект с данными. нужны связанные данные — есть LL, все вытянет. Медленно тянет — используем навороченный кеш итп.
G>>Anemic заставляет думать на каждом этапе: какую модель данных создать? Какие данные загружать для данной опрации? Как кеширование данных сделать? Как группировать методы в сервисы чтобы никто не запустался?
M>Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.
Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.

Здравствуйте, Mike Chaliy, Вы писали:

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

MC>>Вообще я думаю, что все эти споры потому что у каждого человека больше опыта в чем-то одном. Кто-то годами пишет в стиле rich и уже знает как решать все основные задачи и проблемы, но не очень хорошо знает как решать задачи и проблемы встающие при использовании anemic модели. Другой наоборот — годами пишет anemic, а опыта с rich моделью все-таки немного недостаточно, чтобы быть способным эффективно решать имеющиеся там проблемы.

MC>У нас тут маленькая проблемка, у нас тут есть человек кторый считает что очень круто знает и то и другое.

А еще с ним пытаются спорить те, кто ни того ни другого не знают

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

G>>>>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
M>>>Зависит от запроса.
O>> А разве нельзя Equals() переопределить, чтобы было как надо?
MC>Тут видимо имеется в виду что получаются разные instance'ы объектов, а иногда нужно чтобы был только один instance, типа как бы глобальный IdentityMap.

Интересно, а когда это может причинять неудобства, кроме случая ссылочного сравнения объектов?

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

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

G>>>>>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
M>>>>Зависит от запроса.
O>>> А разве нельзя Equals() переопределить, чтобы было как надо?
MC>>Тут видимо имеется в виду что получаются разные instance'ы объектов, а иногда нужно чтобы был только один instance, типа как бы глобальный IdentityMap.

O> Интересно, а когда это может причинять неудобства, кроме случая ссылочного сравнения объектов?

Архитектура корпоративных программных приложений (c) Мартин Фаулер :

В процессе загрузки данных необходимо тщательно следить за тем, чтобы ни один из объектов не был считан дважды, иначе в памяти будут созданы два объекта, соответствующих одной и той же записи таблицы базы данных. Попробуйте обновить каждую из них, и неприятности не заставят себя ждать. Чтобы уйти от проблем, необходимо вести учет каждой считанной записи, а поможет в этом типовое решение коллекция объектов (Identity Map, 216). Каждый раз при необходимости считывания порции данных вначале следует проверить, не содержится ли она в коллекции объектов. Если информация уже загружалась, можно предусмотреть возврат ссылки на нее. В этом случае любые попытки изменения данных будут скоординированы. Еще одно преимущество — возможность избежать дополнительного обращения к базе данных, поскольку коллекция объектов действует как кэш-память. Не забывайте, однако, что главное назначение коллекции объектов — учет идентификационных номеров объектов, а не повышение производительности приложения.

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

Старое изречение гласит: "Человек, который носит две пары часов, никогда не знает, сколько времени". Впрочем, две пары часов — это еще не так серьезно, как загрузка объектов из базы данных. Если вы не будете предельно внимательны, то вполне можете загрузить одни и те же данные в два разных объекта. Легко представить, какая неразбериха начнется, когда вы попытаетесь одновременно внести в базу данных обновления этих объектов...
Описанная ситуация тесно связана и с проблемой производительности. Если одни и те же данные будут загружены несколько раз, это приведет к чрезмерным (и, что самое печальное, совершенно ненужным) расходам на выполнение удаленных вызовов функций. Таким образом, предупреждение повторной загрузки данных не только помогает избежать ошибок, но и значительно ускоряет производительность работы приложения.

Назначение
Как правило, коллекция объектов применяется для управления любыми объектами, которые были загружены из базы данных и затем подверглись изменениям. Основное назначение коллекции объектов — не допустить возникновения ситуации, когда два разных объекта приложения будут соответствовать одной и той же записи базы данных, поскольку изменение этих объектов может происходить несогласованно и, следовательно, вызывать трудности с отображением на базу данных.
Еще одним преимуществом коллекции объектов является возможность использования ее в качестве кэша записей, считываемых из базы данных. Это избавляет от необходимости повторно обращаться к базе данных, если снова понадобится какой-нибудь объект.
Скорее всего, коллекция объектов не понадобится для хранения неизменяемых объектов. Если объект не может быть изменен, вам не нужно беспокоиться о потенциальных конфликтах, связанных с его обновлением. Поскольку объекты-значения (Value Object, 500) являются неизменяемыми, из этого следует, что для работы с ними коллекция объектов, по большому счету, не нужна. Несмотря на это, она может пригодиться и здесь — прежде всего в качестве кэша. Помимо этого, наличие коллекции объектов позволяет предупредить использование некорректного метода проверки на равенство — проблема, весьма распространенная в Java, где нельзя переопределить действие оператора ==.
...
Коллекция объектов помогает избежать конфликтов обновления, возникающих в пределах одного сеанса, однако она бессильна что-либо сделать в случае межсеансовых проблем. Это довольно сложный вопрос, к которому мы вернемся в разделах, посвященных оптимистической автономной блокировке (Optimistic Offline Lock, 434) и пессимистической автономной блокировке (Pessimistic Offline Lock, 445).

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

M>Ну имхо вы усложняете. It depends. В смысле, если сервер был 1, и добавить еще один -- это да, может быть очень заморочисто. А если их было 2 или 3 или больше, то добавить еще один -- обычно совершенно не сложно, т.к. архитектура уже приспособлена к децентрализации.

Даже во втором случае увеличение производительности может быть меньше, если бы выделели больше времени на разработку.
Приведу пример из жизни. Он конешно надуманый, но какой есть
Есть у нас продуманая до мелких деталей машина марки ферари и есть чудо российского автопрома — лада. Сколько лад не покупай, не запрягай в одну упряжку ехать со скоростью ферари они не смогут Зато они смогут вести больше людей. Но что делать, если мне не надо именно быстро ехать, а не обеспечивать транспортом толпу людей, которые никуда не спешат?