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

Задача:
Есть проект, в который входит несколько клиентских приложений (WinForms) для работы с одними и теми же данными — общая БД.
Сейчас принято решение иметь так же одно серверное приложение содержащее либо только слой доступа к данным, либо еще всю или часть бизнес-логики. В сервере в качестве DAL будет использоваться NHibernate с включенным кэшем.
(Решение о централизованном сервере может быть изменено в случае наличия удовлетворительных аргументов.)
Общая проблема:
Наличие коллизий при работе разных клиентов с одними и теми же данными. Т.е., например, оба клиента получили объект, изменили его и отправили обновлять на сервер — в результате произойдет только одно изменение.

Решение N1:
В БД на каждую сущность завести поле с версией сущности, что отразить в маппинге NHibernate.
Основная последовательность:
Клиенты запрашивают у сервера объекты, сервер отдает клиентам отцепленные от кэша сессии объекты. Клиенты их модифицируют и передают для обновления серверу. Сервер пытается прицепить отцепленные объекты и проапдейтить их. В случае если версия объекта не изменилась, апдейтит их, иначе — бросает исключение, клиент его ловит и сообщает пользователю об изменении объекта, пользователь обновляет свой объект и снова пытается его модифицировать, это повторяется пока не будет достигнут успех.
Проблемы решения N1:
1. Вполне может потребоваться некое DTO (представляющее из себя смесь части данных разных объектов) в узких местах, как это DTO реализовывать и как отслеживать его версии? В принципе это не очень критично, но все же очень интересно.
2. Не понятно как реализовать пользовательский интефейс:
а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
— пользователь может забыть это сделать;
— возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
— не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
очень не рад вспоминать что он делал и переделывать.
б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
3. Не может ли произойти параллельное увеличение версии объекта на 1 без обнаружения коллизии? Т.е. сервер получает два запроса на обновление одного и того же объекта и пытается (параллельно, в разных потоках) увеличить версию объекта с 1.0 до 1.1, при этом увеличение происходит одновременно и безконфликтно, в результате чего опять-таки происходит только одно измение, которое затирает результат другого изменения. Понятно, что на практике это очень маловероятно, но все же.
Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.

Решение N2:
Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать.
Проблемы (и вопросы) решения N2:
1. до конца не понятен механизм разруливания коллизий и возможные сложности;
2. как работать с временем жизни объектов?
3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
4. будут ли маршалиться NHibernatе'овские прокси?


Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.

зы Спасибо за внимание!

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

O> 2. Не понятно как реализовать пользовательский интефейс:
O> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
O> — пользователь может забыть это сделать;
Дык отслеживайте изменения, например если клиент хочет закрыть форму или перейти на другую закладку, то проверяйте, были ли сделаны изменения, и если да — сообщайте об этом пользователю с предложением сохранить/не сохранять/отменить действие.

O> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx

Автор: MozgC
Дата: 21.04.09

O> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O> очень не рад вспоминать что он делал и переделывать.
Не нужно все переделывать, нужно оставить введенные изменения пользователя и сообщить ему в чем конкретно ошибка.

O> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
Это просто неправильно так делать.

Ocenochka написав(ла):
> *Задача:*

Ocenochka, вы чего-то не договариваете. Давайте про предметную область,
потому что непонятно вообще с чего городить весь этот огород с
собственным сервером баз данных.

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

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

O> Задача:
O> Есть проект, в который входит несколько клиентских приложений (WinForms) для работы с одними и теми же данными — общая БД.
O> Сейчас принято решение иметь так же одно серверное приложение содержащее либо только слой доступа к данным, либо еще всю или часть бизнес-логики. В сервере в качестве DAL будет использоваться NHibernate с включенным кэшем.
O> (Решение о централизованном сервере может быть изменено в случае наличия удовлетворительных аргументов.)
O> Общая проблема:
O> Наличие коллизий при работе разных клиентов с одними и теми же данными. Т.е., например, оба клиента получили объект, изменили его и отправили обновлять на сервер — в результате произойдет только одно изменение.
Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.

O> Решение N1:
O> В БД на каждую сущность завести поле с версией сущности, что отразить в маппинге NHibernate.
O> Основная последовательность:
O> Клиенты запрашивают у сервера объекты, сервер отдает клиентам отцепленные от кэша сессии объекты. Клиенты их модифицируют и передают для обновления серверу. Сервер пытается прицепить отцепленные объекты и проапдейтить их. В случае если версия объекта не изменилась, апдейтит их, иначе — бросает исключение, клиент его ловит и сообщает пользователю об изменении объекта, пользователь обновляет свой объект и снова пытается его модифицировать, это повторяется пока не будет достигнут успех.
И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.

O> Проблемы решения N1:
O> 1. Вполне может потребоваться некое DTO (представляющее из себя смесь части данных разных объектов) в узких местах, как это DTO реализовывать и как отслеживать его версии? В принципе это не очень критично, но все же очень интересно.
А зачем остлеживать его версии? Одного concurrency token не достаточно (за него вполне можно взять rowversion поле)?

O> 2. Не понятно как реализовать пользовательский интефейс:
O> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
Только так и надо делть.

O> — пользователь может забыть это сделать;
Ему можно напомнить.

O> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
Тебе в любом случае придется changeset формировать, вопрос только в том где и как это делать.

O> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O> очень не рад вспоминать что он делал и переделывать.
Я скажу по секрету, что ты сможешь нарваться на конфликты изменений, которые не будут отловлены твоим механизмом.

O> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
Это буде работать мееееееееееееееедленно. ты ведь забыл что кроме отправки на каждое действие данных на сервер тебе придется передавать изменения на все клиенты или хранить раздельно клиентские сессии.

O>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.

O> Решение N2:
O> Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
O> Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать.
O> Проблемы (и вопросы) решения N2:
O> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O> 2. как работать с временем жизни объектов?
O> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O> 4. будут ли маршалиться NHibernatе'овские прокси?
Это худший вариант развития событий.
1)На любое дергание объекта придется бегать на сервер
2)Все изменения надо передавать клиентам
3)Проблемы с контролем времени жизни

O> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
Оба неадекваты на 99%

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

Ух какая благодарная тема-то

Concurrency control — штука довольно сильно зависящая от предметной области. Мне вот как-то везёт на задачки, когда либо ответственность за изменение данных расписана по людям (и пересечений нет), либо подходит last wins.

Лично я за явный save + возможные проверки перед сохранением. Из опыта людям реально привычно работать в режиме "набросал-поправил-сохранил".

Задача получения изменений в принципе решается легко для внесённых/изменённых строк. С удалёнными строками либо передача всех локальных id на сервер, либо хранение id удалённых строк в вспомогательных табличках на сервере.

На второй вариант забейте сразу.

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

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


O> Решение N2:
O> Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
O> Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать.
O> Проблемы (и вопросы) решения N2:
O> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O> 2. как работать с временем жизни объектов?
O> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O> 4. будут ли маршалиться NHibernatе'овские прокси?


O> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.

O>зы Спасибо за внимание!

День добрый. Не знаю насколько практично маршалить все объекты по ссылке, не разу с таким не сталкивался, но как то настараживает

По существу. Ваши два решения мне напоминают решения с песимистической и оптиместической блокировкой.
В первом случае мы оптимистично надеемся, что никто кроме нас не будет редактировать объект и проверяем это только перед применением изменений. При этом все изменения мы применяем в одной транзакции, чтобы не получилось, что часть изменений прошла, а часть нет. Думаю в NHibernate транзакции есть...
Во втором случае, мы перед тем как приступить к редактированию лочим объект и не отпускаем его до завершения редактирования. В таком случае, мы всегда уверены, что никто не изменил наш объект в то время как мы его редактировали. Возможный выход клиента залочившего объект и не отпустившего блокировку лечится установкой таймаутов.

Минусы первого решения, нужно с минимальными трудозатратами будет показывать пользователю как изменился объект, чтобы он решил перетирать сохраненые другим пользователем данные или нет. Эту проблему вы и сами озвучали.
Минусы второго решения, пользователи не очень любять наблюдать сообщение : "данный объект редактирует другой, пользователь. дождидесь завершения."

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

O>> 2. Не понятно как реализовать пользовательский интефейс:
O>> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
O>> — пользователь может забыть это сделать;
MC>Дык отслеживайте изменения, например если клиент хочет закрыть форму или перейти на другую закладку, то проверяйте, были ли сделаны изменения, и если да — сообщайте об этом пользователю с предложением сохранить/не сохранять/отменить действие.

Не очень понимаю как отслеживать изменения. Допустим на клиенте грид с коллекцией объектов. При редактировании в отдельную коллекцию складывать отредактированные объекты? А как порядок редактирования учитывать?

O>> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
MC>Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx

Автор: MozgC
Дата: 21.04.09

Прочитал. Понял не много и легче не стало. Врапперы над сущностями и их коллекциями — это круто. Не совсем представляю как это будет в случае с несколькими клиентами. DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.

O>> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O>> очень не рад вспоминать что он делал и переделывать.
MC>Не нужно все переделывать, нужно оставить введенные изменения пользователя и сообщить ему в чем конкретно ошибка.

А последовательность изменений не учитывать? Если пятая операция из 10 не прошла, то, на мой взгляд, логично откатить все 10. Соответственно, пользователю прдется переделывать все 10.

O>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
MC>Это просто неправильно так делать.

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

Здравствуйте, Ромашка, Вы писали:

Р>Ocenochka, вы чего-то не договариваете.

Конечно, я целое тз на ~100 стр. недоговариваю тз писал не я и я в него его еще толком не углублялся, однако основные моменты с несколькими клиентами уже известны.

Р>Давайте про предметную область, потому что непонятно вообще с чего городить весь этот огород с собственным сервером баз данных.

Предметная область, на мой взгляд, не имеет значения. Могу сказать, что это не чистые финансы, но такие объекты как "Клиент" и "Счет" имеются.

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

G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.

Прошу кратко аргументировать. Или дать ссылку на развернутое объяснение желательно с минимумом терминологии (она у каждого своя) и с примерами.

O>> Решение N1:
O>> В БД на каждую сущность завести поле с версией сущности, что отразить в маппинге NHibernate.
O>> Основная последовательность:
O>> Клиенты запрашивают у сервера объекты, сервер отдает клиентам отцепленные от кэша сессии объекты. Клиенты их модифицируют и передают для обновления серверу. Сервер пытается прицепить отцепленные объекты и проапдейтить их. В случае если версия объекта не изменилась, апдейтит их, иначе — бросает исключение, клиент его ловит и сообщает пользователю об изменении объекта, пользователь обновляет свой объект и снова пытается его модифицировать, это повторяется пока не будет достигнут успех.
G>И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.

Зачем? Можно их в новой сессии апдейтить. Только проверять сначала версию.

O>> Проблемы решения N1:
O>> 1. Вполне может потребоваться некое DTO (представляющее из себя смесь части данных разных объектов) в узких местах, как это DTO реализовывать и как отслеживать его версии? В принципе это не очень критично, но все же очень интересно.
G>А зачем остлеживать его версии? Одного concurrency token не достаточно (за него вполне можно взять rowversion поле)?

Как раз с помощью rowversion и отслеживать — средствами nhibernate.

O>> 2. Не понятно как реализовать пользовательский интефейс:
O>> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
G>Только так и надо делть.

Мой мозг требует аргументов

O>> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O>> очень не рад вспоминать что он делал и переделывать.
G>Я скажу по секрету, что ты сможешь нарваться на конфликты изменений, которые не будут отловлены твоим механизмом.

Можно на маленьком примере пояснить? Как могут конфликты не быть отловлены, если каждая сущность имеет версию?

O>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
G>Это буде работать мееееееееееееееедленно. ты ведь забыл что кроме отправки на каждое действие данных на сервер тебе придется передавать изменения на все клиенты или хранить раздельно клиентские сессии.

А почему нельзя на клиентов выгружать "оторваные" данные и пытаться их апдейтить с учетом версии? Без наличия обратной связи, т.е. чтобы на клиентах разрешались неактуальные данные пока не потребуется внести изменения.

O>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
G>В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.

Пока не вижу у нас единого взгляда на это решение, учитывая заданные мне вопросы.

G>Это худший вариант развития событий.
G>1)На любое дергание объекта придется бегать на сервер
G>2)Все изменения надо передавать клиентам
G>3)Проблемы с контролем времени жизни

Я и сам не склонен к этому варианту.

O>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>Оба неадекваты на 99%

Предлагайте!

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

S>Ух какая благодарная тема-то

Ох и не говорите Это со стороны может весело, а мне делать надо и сроки есть

S>Concurrency control — штука довольно сильно зависящая от предметной области. Мне вот как-то везёт на задачки, когда либо ответственность за изменение данных расписана по людям (и пересечений нет), либо подходит last wins.

К сожалению, не мой случай, хотя может пересечений между разными клиентами будет не так много...

S>Лично я за явный save + возможные проверки перед сохранением. Из опыта людям реально привычно работать в режиме "набросал-поправил-сохранил".
S>Задача получения изменений в принципе решается легко для внесённых/изменённых строк. С удалёнными строками либо передача всех локальных id на сервер, либо хранение id удалённых строк в вспомогательных табличках на сервере.

Тут логика понятно, но как это реализовывать? На клиенте держать список(списки) изменений — это ладно. А на сервер передавать то же этот список? Или на сервере только методы по редактированию, а клиент сам знает логику работы со списком измененных и дергает нужные методы сервера?

Предлагаю сделать шаг назад и убрать все принятые архитектурные решения относительно единого сервера и наличия NHibernate.
Задача:
Есть несколько клиентских приложений для работы с общими данными. Нужно исключить коллизии при одновременной работе пользователей.
Вариант 1.
Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении.
Вариант 2.
Пытаться всеми силами держать на клиентах только актуальные данные.

В первом варианте недостатком является "относительно небольшая" возможность введения пользователя в заблуждение и необходимость контролировать версии оторванных от БД объектов при применении изменений.
Во втором случае контроль коллизий остается, а заблуждение пользователя устаняется необходимостью работы с DataSet'ами и написание общирной инфраструктуры для поддержания данных на клиенте в актуальном состоянии.

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

Ocenochka написав(ла):
> Предметная область, на мой взгляд, не имеет значения. Могу сказать, что
> это не чистые финансы, но такие объекты как "Клиент" и "Счет" имеются.

И ты ради таких объектов, как "Клиент" и "Счет", собрался городить весь
геморрой с трехзвенкой? Зачем? У тебя шансов нарваться на коллизию ноль
целых ноль десятитысячных.

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

O> К сожалению, не мой случай, хотя может пересечений между разными клиентами будет не так много...
Гммм... а что у вас за случай-то такой страшный?

[offtop]
Спорно конеш, но пересечение больших unit of work чаще всего говорит о бардаке на предприятии.
[/offtop]

O> Тут логика понятно, но как это реализовывать?

Как варинант (выше уже писали):
http://msdn.microsoft.com/ru-ru/library/ms182776.aspx
Запоминать rowersion и передавать этот обратно при сохранении изменений.

Сервер сам решает, можно ли перезаписывать данные и кидает исключение в случае чего.
Или фильтр UPDATE...WHERE...ver=@oldVersion и проверять @@ROWCOUNT.

Клиент ловит исключение — дальше по обстоятельствам. Скорее всего, диалог пользователю -> частичный Upsert и продолжение/перезапуск транзакции (лично я за перезапуск).

Здравствуйте, Ромашка, Вы писали:

Р>И ты ради таких объектов, как "Клиент" и "Счет", собрался городить весь
Р>геморрой с трехзвенкой? Зачем? У тебя шансов нарваться на коллизию ноль
Р>целых ноль десятитысячных.

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

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

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

O>> К сожалению, не мой случай, хотя может пересечений между разными клиентами будет не так много...
S>Гммм... а что у вас за случай-то такой страшный?

Даже не знаю как рассказать... Довольно специфично, думаю никто тут не сталкивался с этой предметной областью. Давайте считать, что это продажа билетов на самолеты с дополнительными услугами. Например, клиенту можно продать кроме самого полета еще и обед, а можно скидку сделать. При этом число доп. услуг ограничено и билеты мужду двумя точками могут иметь разную стоимость и разную траекторию полета. Примерно так. Т.е. продажа пакетов взаимосвязанных услуг.
Не хочется завязываться на конкретные условия, т.к. они часто изменчивы и то, что не нужно сегодня может потребоваться завтра, а переписывать из-за этого всю архитектуру... сами понимаете.

S>[offtop]
S>Спорно конеш, но пересечение больших unit of work чаще всего говорит о бардаке на предприятии.
S>[/offtop]
Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save".

O>> Тут логика понятно, но как это реализовывать?
S>Как варинант (выше уже писали):
S>http://msdn.microsoft.com/ru-ru/library/ms182776.aspx
S>Запоминать rowersion и передавать этот обратно при сохранении изменений.
S>Сервер сам решает, можно ли перезаписывать данные и кидает исключение в случае чего.
S>Или фильтр UPDATE...WHERE...ver=@oldVersion и проверять @@ROWCOUNT.
S>Клиент ловит исключение — дальше по обстоятельствам. Скорее всего, диалог пользователю -> частичный Upsert и продолжение/перезапуск транзакции (лично я за перезапуск).

Спасибо, этот вариант мне примерно пока понятен.

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

O> Вариант 1.
O> Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении.

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

O> Вариант 2.
O> Пытаться всеми силами держать на клиентах только актуальные данные.

Что значит акутальные? Актуальные они только в базе, за ее пределами уже актуальности нет.

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

O>> Вариант 1.
O>> Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении.
Z>Они все равно будут оторваные, вопрос только в том, насколько часто обновляются. Возможно достаточно ручного обновления, как сделано в браузере. Частота обновления определяется требованиями. Актуальность при изменении придется проверять в любом случае. Ибо вариант сохранения изменений в удаленном кем-то другим объекте все равно весьма вероятен. Что делать в таких случаях все равно определяют требования к приложению.

Согласен, имелось ввиду, что за счет значительного уменьшения времени обновления (обратная связь) данные будут крайне редко находится в неактуальном состоянии.

O>> Вариант 2.
O>> Пытаться всеми силами держать на клиентах только актуальные данные.
Z>Что значит акутальные? Актуальные они только в базе, за ее пределами уже актуальности нет.

Значит, что будет механизм обратной связи от БД — в случае изменеия данных на сервере клиенты будут об этом уведомляться.

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

O> Значит, что будет механизм обратной связи от БД — в случае изменеия данных на сервере клиенты будут об этом уведомляться.

Не завидую человеку редактирющему постоянно обновляемый документ. Не завидую программисту пишущему УИ для этого.

Вобщем я к чему — это сложно написать и с этим будет неприятно работать, какие плюсы это дает, чтобы перевести такие минусы?

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

O>> Значит, что будет механизм обратной связи от БД — в случае изменеия данных на сервере клиенты будут об этом уведомляться.
Z>Не завидую человеку редактирющему постоянно обновляемый документ. Не завидую программисту пишущему УИ для этого.
Z>Вобщем я к чему — это сложно написать и с этим будет неприятно работать, какие плюсы это дает, чтобы перевести такие минусы?

Плюс один — наличие актуальных данных на клиентах. Вообще-то, я согласен, но хочется рассмротреть все варианты пока есть возможность.

Здравствуйте, Ocenochka

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

Хотите расскажу страшную тайну?
РЖД довольно долго резервировало за отдельными регионами диапазоны билетов и переодически делало синхронизацию. Учитесь

А для вашего сценария давно придуманы блокировки намерения: вы говорите серверу "я зарезервировал этот ресурс тогда-то" и периодически обновляете время "захвата". Захват кем-то другим возможен по истечении интервала, который заведомо больше интервала обновления. Для красоты можно прикрутить сборку мусора по расписанию.

Если блокировка ставится в Serializable транзакции, коллизий не будет. В Sql Server'e есть ещё и application locks: http://www.sqlteam.com/article/application-locks-or-mutexes-in-sql-server-2005. Я их детально не копал — ничего не подскажу.

То есть вы говорите "я собираюсь использовать такие-то ресурсы, честное слово", а все остальные клиенты радостно вам верят и ничего не портят

Аппсервер вам ничем не поможет в плане когерентности данных. Наоборот отхватите проблем. // Не-не, никакого холивара. Я говорю только о concurrency management силами аппсервера.

O>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save".
Некорректно выразился. Важен не размер а продолжительность.

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

O>>Даже не знаю как рассказать... Довольно специфично, думаю никто тут не сталкивался с этой предметной областью. Давайте считать, что это продажа билетов на самолеты с дополнительными услугами.
S>Хотите расскажу страшную тайну?
S>РЖД довольно долго резервировало за отдельными регионами диапазоны билетов и переодически делало синхронизацию. Учитесь

А как насчет поддержания в актуальном состоянии базы внутри региона? Если разные кассы параллельно продают билеты из одного зарезервированного диапазона?

S>А для вашего сценария давно придуманы блокировки намерения: вы говорите серверу "я зарезервировал этот ресурс тогда-то" и периодически обновляете время "захвата". Захват кем-то другим возможен по истечении интервала, который заведомо больше интервала обновления. Для красоты можно прикрутить сборку мусора по расписанию.

Не совсем представляю как применить это в моем случае. У меня резервирование равносильно продаже, потому как регион только один.

S>Аппсервер вам ничем не поможет в плане когерентности данных. Наоборот отхватите проблем. // Не-не, никакого холивара. Я говорю только о concurrency management силами аппсервера.

Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
Вообще, я сам пока не вижу причин, почему на каждом клиенте не иметь свой кэш, раз уж все равно данные оторваны от БД. А кэш обновлять по мере необходимости. Или вообще не иметь кэша — все равно все операции редактирования (insert/update/delete) нужно будет отправлять в БД по требованию.

O>>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save".
S>Некорректно выразился. Важен не размер а продолжительность.

Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.

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

O>>>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save".
S>>Некорректно выразился. Важен не размер а продолжительность.

O> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
Речь не о скорости обновления, а о том что пользователь мог начать редактировать и уехать на обед не закончив.

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

O>> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
S>Речь не о скорости обновления, а о том что пользователь мог начать редактировать и уехать на обед не закончив.

Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка. В оптимистической блокировке можно таймаут сделать и опять-таки обламать ушедшего на обед. Другими словами, в моем случае такой клиент не прав. Общие данные не будут большими документами, а только бизнес-сущностями с несколькими, ну может десятками, свойств.

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

O> А как насчет поддержания в актуальном состоянии базы внутри региона? Если разные кассы параллельно продают билеты из одного зарезервированного диапазона?

Гммм... вообще-то это был стёб на тему как делать не надо — разделение на диапазоны работало крайне отвратительно (никакого отношения к РЖД не имею, источник тоже давно оттуда ушёл — в 2004-м вроде).

O> Не совсем представляю как применить это в моем случае. У меня резервирование равносильно продаже, потому как регион только один.

У вас дело в том чтобы не продать один и тот же ресурс несколько раз, так?
Так вот. Когда вы начинаете обслуживать реального клиента (человека), вы ставите блокировку намерения ("щас продам!") и периодически её изменяете.

Если вам не удалось поставить блокировку — вы не можете ничего продать и всё

Учтите, что тут не совсем блокировка с точки зрения СУБД, это тупо флажок "зарезервировано для продажи".

O> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?

Аппсервер даёт выигрыш в масштабировании за счёт того что все сессии не хранят состояние. Как только вы начинаете согласовывать состояния разных клиентов, вы получаете обратно проблемы с блокировками и прощай масштабируемость. Быстродействие одного клиента от аппсервера не выиграет никак.

S>>Некорректно выразился. Важен не размер а продолжительность.
O> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
Ухх... продолжительность не save а всего сеанса обслуживания — вам же придётся держать блокировку намерения всё время чтобы никто не отобрал у вас ресурс.

O> Вообще, я сам пока не вижу причин, почему на каждом клиенте не иметь свой кэш, раз уж все равно данные оторваны от БД. А кэш обновлять по мере необходимости. Или вообще не иметь кэша — все равно все операции редактирования (insert/update/delete) нужно будет отправлять в БД по требованию.

Всё что я писал не отменяет кэша — это просто способ захвата свободных ресурсов без удержания сессии.

Приведите в общем последовательность действий когда вы получите конфликт при сохранении. И посмотрите что будет если резервировать ресурсы по мере необходимости.

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

O> Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка.
При пессимистической блокировке другие клиенты не смогут отредактировать документ, пока уехавший на обед не сделает Save или Cancel. А тот сценарий который ты описал — оптимистический.

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

G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.

Тем, что требует DTO для передачи данных?

Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO. То, что называется тонком моделю по сути моделью не является, это DTO, моделью для которых служит БД. Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели). В жирной модели между БД и приложением появляется еще один слой — модель предметной области, которая реально является моделью, которую разработать не проще чем модель физического процесса и оправдывает она себя лишь на каком-то пороге сложности предметной области.

У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель. Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.

Вобщем Фаулер и Эванс не пропагандируют overarchitect, они лишь рассказыват как подняться на еще одну ступеньку в борьбе со сложностью продукта. Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.

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

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

O>> А как насчет поддержания в актуальном состоянии базы внутри региона? Если разные кассы параллельно продают билеты из одного зарезервированного диапазона?
S>Гммм... вообще-то это был стёб на тему как делать не надо — разделение на диапазоны работало крайне отвратительно (никакого отношения к РЖД не имею, источник тоже давно оттуда ушёл — в 2004-м вроде).

В начале подумал, что стеб, а потом решил, что "не мог же ржд работать не правильно"

O>> Не совсем представляю как применить это в моем случае. У меня резервирование равносильно продаже, потому как регион только один.
S>У вас дело в том чтобы не продать один и тот же ресурс несколько раз, так?

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

S>Так вот. Когда вы начинаете обслуживать реального клиента (человека), вы ставите блокировку намерения ("щас продам!") и периодически её изменяете.
S>Если вам не удалось поставить блокировку — вы не можете ничего продать и всё
S>Учтите, что тут не совсем блокировка с точки зрения СУБД, это тупо флажок "зарезервировано для продажи".

В моем случае, не критично, если кассир скажет, что билет есть, начнет процедуру введения данных пользователя а в итоге (при нажатии на кнопку "Save") обломится, потому что-то кто-то успеет продать этот билет раньше. Таких случаев наверняка будет не много. Хотя лочить продаваемый билет при начале ввода данных то же хороший вариант, только требующий дополнительных усилий.

O>> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
S>Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?

Да

S>Аппсервер даёт выигрыш в масштабировании за счёт того что все сессии не хранят состояние. Как только вы начинаете согласовывать состояния разных клиентов, вы получаете обратно проблемы с блокировками и прощай масштабируемость. Быстродействие одного клиента от аппсервера не выиграет никак.

Под масштабированием подразумевается увеличение числа клиентов?

S>>>Некорректно выразился. Важен не размер а продолжительность.
O>> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
S>Ухх... продолжительность не save а всего сеанса обслуживания — вам же придётся держать блокировку намерения всё время чтобы никто не отобрал у вас ресурс.

Если правильно понял, то подразумевается что-то вроде продолжительности оформления продажи? Нет, не большая продолжительность.

O>> Вообще, я сам пока не вижу причин, почему на каждом клиенте не иметь свой кэш, раз уж все равно данные оторваны от БД. А кэш обновлять по мере необходимости. Или вообще не иметь кэша — все равно все операции редактирования (insert/update/delete) нужно будет отправлять в БД по требованию.

S>Всё что я писал не отменяет кэша — это просто способ захвата свободных ресурсов без удержания сессии.
S>Приведите в общем последовательность действий когда вы получите конфликт при сохранении. И посмотрите что будет если резервировать ресурсы по мере необходимости.

Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных?
Т.е. придется обновлять данные не только после процедуры оформления, но и перед, чтобы убедиться, что ресурс не занят и занять его?
Да, в случае длительных операций с большим числом ввода данных от пользователя это имеет смысл, согласен.

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

O>> Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка.
IB>При пессимистической блокировке другие клиенты не смогут отредактировать документ, пока уехавший на обед не сделает Save или Cancel. А тот сценарий который ты описал — оптимистический.

Ясно, спасибо, различие и плюсы обоих случаев уловил.

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

G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
Z>Тем, что требует DTO для передачи данных?

Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.

Z>Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO. То, что называется тонком моделю по сути моделью не является, это DTO, моделью для которых служит БД. Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели). В жирной модели между БД и приложением появляется еще один слой — модель предметной области, которая реально является моделью, которую разработать не проще чем модель физического процесса и оправдывает она себя лишь на каком-то пороге сложности предметной области.
Z>У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель.

Тут все об одном и том же — о производительности, с чем я согласен, однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру. Поэтому я и написал, что в моем понимании адекватность реализации оценивается не скоростью работы, а в первую очередь временем написания/отладки/поддержки.

Z>Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.
Z>Вобщем Фаулер и Эванс не пропагандируют overarchitect, они лишь рассказыват как подняться на еще одну ступеньку в борьбе со сложностью продукта. Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.

Согласен, однако рассуждения на эту тему плохо вписываются в топик

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

O> В начале подумал, что стеб, а потом решил, что "не мог же ржд работать не правильно"
А почему? Наоборот очень полезно искать косяки у авторитетов — у них как правило и косяки покруче обычных.

O> В моем случае, не критично, если кассир скажет, что билет есть, начнет процедуру введения данных пользователя а в итоге (при нажатии на кнопку "Save") обломится.

Неее, это со стороны как жуткий отстой смотрится: "ой, у нас система не работает" против "вы знаете, все билеты разобраны"
Усилия здесь окупятся — там работы на 5 минут — добавить метод TryReserveResource и обновлять блокировку по памяти.

O>>> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
S>>Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?

O> Да
А зачем им — пользователь должен выбирать? Тогда в 2 этапа — при начале обслуживания забираете свободные ресурсы, а потом перебором пытаетесь лочить

O> Под масштабированием подразумевается увеличение числа клиентов?
Да

O> Если правильно понял, то подразумевается что-то вроде продолжительности оформления продажи? Нет, не большая продолжительность.
Ага. Тогда всё вообще классно — достаточно в принципе загрузки данных в начале работы + проверки при сохранении.

O> Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных?

Тут не совсем пессимистическая блокировка — последняя подразумевает удержание сессии и полную невозможность поломать состояние. А вариант с "зарезервировано" дешевле в плане масштабируемости, но уязвимей к некорретному изменению данных. Но да, нечто похожее.

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

G>>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
Z>>Тем, что требует DTO для передачи данных?

O> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.

Мы до сих пор говорим о жирной модели? Этот термин был придуман IB и означал модель, классы которой содержат логику, в отличии от тощей, в которой объекты служат лишь хранилищем данных.

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

O>> В начале подумал, что стеб, а потом решил, что "не мог же ржд работать не правильно"
S>А почему? Наоборот очень полезно искать косяки у авторитетов — у них как правило и косяки покруче обычных.

Мне поиска косяков у себя хватает Хотя иногда все же пускаюсь в рассуждения относительно того как сделано у "авторитетов", но скорее для развлечения и поиска дыр, чем действительно с желанием досконально рзобраться ибо в абсолютном большинстве случаем до правды докопаться не удается.

O>> В моем случае, не критично, если кассир скажет, что билет есть, начнет процедуру введения данных пользователя а в итоге (при нажатии на кнопку "Save") обломится.

S>Неее, это со стороны как жуткий отстой смотрится: "ой, у нас система не работает" против "вы знаете, все билеты разобраны"

Скорее так: "Ой, а этот билет только что кто-то уже купил, хотите другой?". К тому же это будет происходить крайне редко, скорее всего.

S>Усилия здесь окупятся — там работы на 5 минут — добавить метод TryReserveResource и обновлять блокировку по памяти.

Вообще да, согласен.

O>>>> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
S>>>Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?
O>> Да
S>А зачем им — пользователь должен выбирать? Тогда в 2 этапа — при начале обслуживания забираете свободные ресурсы, а потом перебором пытаетесь лочить

Ну да, как то так.

O>> Под масштабированием подразумевается увеличение числа клиентов?
S>Да

Ясно, согласен.

O>> Если правильно понял, то подразумевается что-то вроде продолжительности оформления продажи? Нет, не большая продолжительность.
S>Ага. Тогда всё вообще классно — достаточно в принципе загрузки данных в начале работы + проверки при сохранении.
O>> Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных?
S>Тут не совсем пессимистическая блокировка — последняя подразумевает удержание сессии и полную невозможность поломать состояние. А вариант с "зарезервировано" дешевле в плане масштабируемости, но уязвимей к некорретному изменению данных. Но да, нечто похожее.

А как можно некорректно изменить данные, которые имеют версию? Два лока сделать одновременно ведь не удасться даже теоретически, на сколько я понимаю.

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

G>>>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
Z>>>Тем, что требует DTO для передачи данных?
O>> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
Z>Мы до сих пор говорим о жирной модели? Этот термин был придуман IB и означал модель, классы которой содержат логику, в отличии от тощей, в которой объекты служат лишь хранилищем данных.

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

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

O> Вариант 1.
O> Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении.

O> В первом варианте недостатком является "относительно небольшая" возможность введения пользователя в заблуждение и необходимость контролировать версии оторванных от БД объектов при применении изменений.

Если я правильно понимаю, что вам предстоит делать, то я бы мог предложить такое развитие первого варианта.
При запросе данных о билетах у вас уже сразу есть естественный фильтр по направлению полета или даже по конкретному рейсу. Результат запроса с учетом этого фильтра вы можете кешировать, но автоматически обновлять его не надо. Предоставьте просто возможность обновить его целиком по требованию пользователя. Но при этом, когда пользователь начнет редактировать/бронировать конкретый билет, вы на автомате обновите информацию только по этому билету (может быть и блокировку на него сразу навесите — это повкусу). Главное не надо стараться обновлять постоянно все закешированные данные.

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

O>> Вариант 1.
O>> Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении.

O>> В первом варианте недостатком является "относительно небольшая" возможность введения пользователя в заблуждение и необходимость контролировать версии оторванных от БД объектов при применении изменений.

I>Если я правильно понимаю, что вам предстоит делать, то я бы мог предложить такое развитие первого варианта.
I>При запросе данных о билетах у вас уже сразу есть естественный фильтр по направлению полета или даже по конкретному рейсу. Результат запроса с учетом этого фильтра вы можете кешировать, но автоматически обновлять его не надо. Предоставьте просто возможность обновить его целиком по требованию пользователя. Но при этом, когда пользователь начнет редактировать/бронировать конкретый билет, вы на автомате обновите информацию только по этому билету (может быть и блокировку на него сразу навесите — это повкусу). Главное не надо стараться обновлять постоянно все закешированные данные.

Ага, спасибо, об этом уже подумал.

Ocenochka написав(ла):
> *Задача:*
> Есть несколько клиентских приложений для работы с общими данными. Нужно
> исключить коллизии при одновременной работе пользователей.
> *Вариант 1.*
> Разрешить на клиентах иметь оторванные от БД данные и проверять их
> актуальность при изменении.
> *Вариант 2.*
> Пытаться всеми силами держать на клиентах только актуальные данные.
Вариант 3.
Разрешить на клиентах иметь оторванные от БД данные, но при возможности
их изменения не давать их изменять другим клиентам. То есть, открывая на
изменение объект "Счет", лочить его на уровне бизнес-логики или БД.
Перед открытием проверять не залочен ли он.

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

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

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

O> однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру.

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

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

O>> однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру.
I>Поубивал бы тех, кто пустил эту фразу в народ
I>Мало того, что перекладывание своих проблем на кошелек заказчика,

А разработчики, типа, бесплатно будут ковыряться в кривой архитектуре? Хорошо, если найдете адекватного и согласного копаться в существующем решении Месяц работы 1 разработчика примерно равен стоимости хорошего сервера, а то и двух.

I>так еще святая вера в то, что просто добавление еще одного сервера улучшит производительность.

При наличии соответствующей архитектуры — улучшит. Именно поэтому хорошая архитектура — "залог здоровья". А в условиях активного развития средств виртуализации и без правельной архитектуры может улучшить, на сколько я понимаю.

I>А какие изменения в архитектуру ПО вы собираетесь вносить, чтобы ваше приложение хотя бы не стало медленей работать от добавления еще одного сервера?

Ну чтобы заработало и при этом медленнее чем было — это надо постараться
СУБД вроде хорошо масштабируются, web и win сервисы то же, конечно правильно написаные. Конечно, может быть централизованная архитектура, которая ни чего не даст при покупке дополнительного сервера, но я это не рассматривал — это крайний случай.


зы Еще одна фраза "выпущенная в народ": девять женщин не родят ребенка за один месяц
Что в тематике форума будет звучать, как "9 месяцев работы одного программиста не равны одному месяцу работы 9 программистов в проекте на 9 чел./мес."
Это к вопросу увеличения производительности при добавлении разработчиков и при добавлении серверов

Здравствуйте, Ромашка, Вы писали:

Р>Вариант 3.
Р>Разрешить на клиентах иметь оторванные от БД данные, но при возможности
Р>их изменения не давать их изменять другим клиентам. То есть, открывая на
Р>изменение объект "Счет", лочить его на уровне бизнес-логики или БД.
Р>Перед открытием проверять не залочен ли он.

Спасибо, уже рассмотрели. Это скорее разновидность первого варианта.

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

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

G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.

O>Прошу кратко аргументировать. Или дать ссылку на развернутое объяснение желательно с минимумом терминологии (она у каждого своя) и с примерами.
Описанные проблемы обоих решений — уже аргумент.

O>>> 2. Не понятно как реализовать пользовательский интефейс:
O>>> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
G>>Только так и надо делть.
O> Мой мозг требует аргументов

O>>> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O>>> очень не рад вспоминать что он делал и переделывать.
G>>Я скажу по секрету, что ты сможешь нарваться на конфликты изменений, которые не будут отловлены твоим механизмом.

O> Можно на маленьком примере пояснить? Как могут конфликты не быть отловлены, если каждая сущность имеет версию?
Спокойно. Версия не будет проверяться если не было никаких изменений. Если у вас корректность данных зависит от совокупности сущностей и один клиент меняет одну, а другой — другую, то такой конфликт не может быть отловлен.

O>>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
G>>Это буде работать мееееееееееееееедленно. ты ведь забыл что кроме отправки на каждое действие данных на сервер тебе придется передавать изменения на все клиенты или хранить раздельно клиентские сессии.
O> А почему нельзя на клиентов выгружать "оторваные" данные и пытаться их апдейтить с учетом версии? Без наличия обратной связи, т.е. чтобы на клиентах разрешались неактуальные данные пока не потребуется внести изменения.
А в какой момент мерджить изменения? Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
Если не save, то постоянная обратная связь со всеми вытекающими.

O>>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
G>>В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.
O> Пока не вижу у нас единого взгляда на это решение, учитывая заданные мне вопросы.
А ты подробнее распиши задачу и покажи свои наработки. Создавать сферическую архитектуру в вакууме не получится.

O>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>Оба неадекваты на 99%
O> Предлагайте!
Сделать кнопку Save, по которой сохранять изменения.
Далее 3 варианта:
1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)
2)Написать кучу сервисов и DTO
3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services

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

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

G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.

Z>Тем, что требует DTO для передачи данных?
Не только.

Z>Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO.
Различий гораздо больше.
Пример — нужно получить список заказов с адресом клиента и фамилией менеджера, отвественного за заказ.
В жирной модели надо загрузить список заказов, для каждого заказа надо загрузить полный объект менеджера и клиента.


Z>То, что называется тонком моделю по сути моделью не является, это DTO, моделью для которых служит БД.
Это бред воспаленного сознания.
ER-модели (модели данных) начали применяться гораздо раньше, чем ООП. Стройная модель — как раз отражение модели данных в программе.
Причеем между моделью данных и схемой хранения может быть достаточно нетривиальынй маппинг.

Z>Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели).
Смысл этой фразы для меня остался загадкой.

Z>В жирной модели между БД и приложением появляется еще один слой — модель предметной области, которая реально является моделью, которую разработать не проще чем модель физического процесса и оправдывает она себя лишь на каком-то пороге сложности предметной области.
Практика показывает обратное. На каком-то пороге сложности domain model перестает оправдывать себя.

Z>У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель. Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.
Это за счет чего достигается? Магией чтоли?
И что вообще означает "не позволяет нарушить ни одного бизнес правила", если программа чего-то такого допускает, то это бага.
Кстати, а что означает "дает максимально полный интерфейс для работы над собой"?

Z>Вобщем Фаулер и Эванс не пропагандируют overarchitect, они лишь рассказыват как подняться на еще одну ступеньку в борьбе со сложностью продукта.
Угу, борьба со сложностью способом увеличения сложности — замечательно.

Z>Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.
Пример такого случая будет?

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

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

G>>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
Z>>Тем, что требует DTO для передачи данных?

O> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
Тогда это будет не domain model

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

G>>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
O>>Прошу кратко аргументировать. Или дать ссылку на развернутое объяснение желательно с минимумом терминологии (она у каждого своя) и с примерами.
G>Описанные проблемы обоих решений — уже аргумент.

Проблемы первого решения для меня еще не являются агрументом для отказа от domain model.

O>>>> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
O>>>> очень не рад вспоминать что он делал и переделывать.
G>>>Я скажу по секрету, что ты сможешь нарваться на конфликты изменений, которые не будут отловлены твоим механизмом.
O>> Можно на маленьком примере пояснить? Как могут конфликты не быть отловлены, если каждая сущность имеет версию?
G>Спокойно.

Интересно, что в моем предложении заставило вас считать, что я не спокоен?

G>Версия не будет проверяться если не было никаких изменений. Если у вас корректность данных зависит от совокупности сущностей и один клиент меняет одну, а другой — другую, то такой конфликт не может быть отловлен.

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

O>> А почему нельзя на клиентов выгружать "оторваные" данные и пытаться их апдейтить с учетом версии? Без наличия обратной связи, т.е. чтобы на клиентах разрешались неактуальные данные пока не потребуется внести изменения.
G>А в какой момент мерджить изменения?

Да, при нажатии на Save, однако, мержить не выйдет — только потеря изменений, обновление и последующая попытка изменения. Ну может получится смержить, но это отдельная проблема, которую пока можно не рассматривать.

G>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.

Как не надо? А как об изменении смогут узнать другие клиенты?

G>Если не save, то постоянная обратная связь со всеми вытекающими.

Обратная связь относится к решению N2. Как организовать такое решение я пока что не услышал. Выгружать на каждого клиента датасеты и городить соответственную инфраструктуру, на мой взгляд, много сложнее, тем более, что это все равно не спасет от проверки версий объектов, не говоря уже о проблемах, когда клиенты теряют связь с сервером.

O>>>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
G>>>В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.
O>> Пока не вижу у нас единого взгляда на это решение, учитывая заданные мне вопросы.
G>А ты подробнее распиши задачу и покажи свои наработки.

Задача занимает сейчас около 100 стр. при этом я не могу понять что даст раскрытие ньюансов конкретной предметной области. Премер я уже приводил. Наработки еще не закончены, однако есть четкое представление архитектуры.

G>Создавать сферическую архитектуру в вакууме не получится.

Однако, глядя на ваши ответы, я считаю, что у вас это вполне получается Без обид. Просто я не вижу у вас понимания решения N1. То, что вы пробовали городить dataset'ы — это я уже выяснил и то что опыта с orm и domain model не имели то же выяснил

O>>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>>Оба неадекваты на 99%
O>> Предлагайте!
G>Сделать кнопку Save, по которой сохранять изменения.
G>Далее 3 варианта:
G>1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)

В задаче сказано, что БД — одна.

G>2)Написать кучу сервисов и DTO

Это зачем и к чему?

G>3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services

Каким образом?

Есть четкая задача, которую я обозначил дважды, повторю еще раз: есть два клиента, работающих с общей БД. Как реализовать их работу при отсутствии коллизий?

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

O>> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
G>Тогда это будет не domain model

Жду определения
Вы же сами называли это тонкой domain model.

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

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

O>>> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
G>>Тогда это будет не domain model

O> Жду определения
O> Вы же сами называли это тонкой domain model.
Обычно под понятием domain model понимают rich. Потому что фаулер в своей книге именно так и описал.

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

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

O> Задача:
O> Есть проект, в который входит несколько клиентских приложений (WinForms) для работы с одними и теми же данными — общая БД.
O> Сейчас принято решение иметь так же одно серверное приложение содержащее либо только слой доступа к данным, либо еще всю или часть бизнес-логики. В сервере в качестве DAL будет использоваться NHibernate с включенным кэшем.
O> (Решение о централизованном сервере может быть изменено в случае наличия удовлетворительных аргументов.)
O> Общая проблема:
O> Наличие коллизий при работе разных клиентов с одними и теми же данными. Т.е., например, оба клиента получили объект, изменили его и отправили обновлять на сервер — в результате произойдет только одно изменение.

O> Решение N1:

O> Решение N2:

O> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.

O>зы Спасибо за внимание!

Добрый день.

Хочу попробовать помочь, высказав свои соображения.

Прежде всего, вариант N2 следует отмести как нереализуемый -- уж очень много всяких косяков там вылезает: начиная от проблем с проксями NHibernate и заканчивая сбоями сети. Кроме того, работа по сети в таком случае выльется в безобразные тормоза на клиенте.

Итак, остается вариант №1, которым обычно и пользуются при написании 3хзвенок.
Чтобы претворить его в жизнь, нужно:
1) Определиться с генератором DTO: будет он или вы сами будете гонять отсоединенные объекты (DTO можно готовить и руками, но лучше взять что-либо типа otis lib);
2) Кнопка Save в вашем случае -- отличное решение; нужно только определиться с сеансами редактирования (т.е. где эти кнопки будут находиться и каковы будут участки, работа на которых идет от сохранения до сохранения;
3) Определиться с тем, как вы будете решать конфликты одновременного обновления: пессимистический вариант и оптимистический, соотственно.
В случае пессимистического вы не допускаете конфликтов -- при помощи транзакций БД(хардкор, но иногда допустим или на уровне бизнес-транзакций (т.н. conversation), помечая и блокируя бизнес-объекты , находящиеся в редактировании;
В случае оптимистического варианта вы решаете разруливать конфликты одновременного обновления по факту обнаружения таких конфликтов. Вариантов здесь а)затирать старые изменения (игнорируем конфликт) б) не давать затирать при помощи проверки версии (NHibernate вам в помощь) и просить пользователя внести вторично правку в устаревшие данные в) реализовать стратегию merge данных, если данные могут быть объединены без логического конфликта
Ничего не мешает сочетать эти варианты, согласуясь с другими критериями. Да, и ответ на ваш вопрос -- NHibernate сам умеет поддерживать версии объекта, так что коллизий не будет; если вам интересно, я напишу следующим сообщением, почему описанная вами ситуация не случится.
4) Определитесь со стратегией кеша и провайдером кеша (не все из них поддерживают блокировку объектов!). Со своей стороны могу порекомендовать SharedCache.net, ибо пробовал, понравилось; memcached не пробовал, но буду в след. проекте;
5) Определиться со стратегией выработки Id(PK) для бизнес-объектов -- некоторые, например, identity, плохо совместимы с NHibernate 2nd level cache.

Если заинтересовало, пишите, продолжим обсуждение трудностей и подводных камней.

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


G>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
O> Как не надо? А как об изменении смогут узнать другие клиенты?
Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать?

O>>>>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
G>>>>В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.
O>>> Пока не вижу у нас единого взгляда на это решение, учитывая заданные мне вопросы.
G>>А ты подробнее распиши задачу и покажи свои наработки.

O> Задача занимает сейчас около 100 стр. при этом я не могу понять что даст раскрытие ньюансов конкретной предметной области. Премер я уже приводил. Наработки еще не закончены, однако есть четкое представление архитектуры.
Может дать очень много потому что единственное что сейчас видят люди на форуме — это твое трактование предметной области.

G>>Создавать сферическую архитектуру в вакууме не получится.

O> Однако, глядя на ваши ответы, я считаю, что у вас это вполне получается Без обид.
O>Просто я не вижу у вас понимания решения N1.
Это у тебя нету понимания решения N1, я такие решения в разных видах уже делал.

O>То, что вы пробовали городить dataset'ы — это я уже выяснил
Мимо. Как раз решения с dataset я предпочитаю не городить, я один раз начал такое делать и быстро отказался.

O>и то что опыта с orm и domain model не имели то же выяснил
Совсем мимо. С orm работаю постоянно и даже свой писал.

Хреновый из тебя телепат.

O>>>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>>>Оба неадекваты на 99%
O>>> Предлагайте!
G>>Сделать кнопку Save, по которой сохранять изменения.
G>>Далее 3 варианта:
G>>1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)
O> В задаче сказано, что БД — одна.
И что? SQL CE — несколько dll и больше ничего не надо

G>>2)Написать кучу сервисов и DTO
O> Это зачем и к чему?
Ко всему. Если клиент не толстый, то лучше увеличить гранулярность обращения к серверу. Для этого потребуется метод сервиса и вероятнее всего DTO.

G>>3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services
O> Каким образом?
Создть модель в EF дизайнере, создать сервис ADO.NET, сделать клиент.

O> Есть четкая задача, которую я обозначил дважды, повторю еще раз: есть два клиента, работающих с общей БД. Как реализовать их работу при отсутствии коллизий?
Наверное при наличии коллизий. Варианта как всегда два:
1)пессимистичная блокировка — когда данные могут меняться только одним клиентом в один момент времени.
2)оптимистичная блокировка, когда оба редактируют данные, если при попытке сорхнанить версии не сопадают — исправить конфликт и попытаться еще раз.
Оптимистичная блокировка на самом деле блокировкой не является, несмотря на назание, и в некоторых случаях не работает.
Проверка версии происходит только при явном сохранении (кнопка save), причем проверяется средствами БД.

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

O>Не очень понимаю как отслеживать изменения. Допустим на клиенте грид с коллекцией объектов. При редактировании в отдельную коллекцию складывать отредактированные объекты? А как порядок редактирования учитывать?
Вы видимо невнимательно прочитали тему. Либо реализовывать флаг IsDirty в самом бизнес-объекте (базовом классе), либо использовать Wrapper, который будет отслеживать изменения обертываемого объекта и реализовывать флаг IsDirty. Если нужно учитывать порядок редактирования — это отдельная задача, но лично мне никогда не нужно было учитывать порядок редактирования. Вы уверены что вы заранее не усложняете задачу зачем-то?

O>>> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
MC>>Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx

Автор: MozgC
Дата: 21.04.09

O>Прочитал. Понял не много и легче не стало.
Может стоит еще раз внимательно прочитать? Я серьезно.

O>Врапперы над сущностями и их коллекциями — это круто. Не совсем представляю как это будет в случае с несколькими клиентами.
Видимо у каждого клиента будет своя коллекция обернутых объектов.

O>DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
В принципе датасеты вариант, но лично мне кажется что они провоцируют дублирование логики, а так же вынос логики в presentation. К тому же нетипизированные датасеты неудобны отсутствием типизации, а типизированные датасеты дают мало контроля, т.к. все генерируется и перегенерируется автоматически.

O>А последовательность изменений не учитывать? Если пятая операция из 10 не прошла, то, на мой взгляд, логично откатить все 10. Соответственно, пользователю прдется переделывать все 10.
Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
Если же вы про облом операции именно по причине коллизии, то тут надо сначала знать, что должно происходить в случае коллизии? Может просто молча должны записаться изменения пользователя (на мой взгляд зачастую это вполне допустимо), или же надо сообщить пользователю о том что в БД уже етсь измененная версия объекта и спросить хочет ли он ее перезаписать? Или же надо перечитать (или просто отдельно показать) измененный объект из БД? Или надо все перечитать? Это вы должны сначала вместе с экспертами предметной области решить как должна вести себя система.

O>>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
MC>>Это просто неправильно так делать.

O>Не правильно делать категоричные заявления без аргументов Ясно, что производительность и отзывчивость могут пострадать, если клиентов будет много, а сервер далеко, но есть подозрение, что дело не в этом.
И в этом тоже. Вы вообще искренне считаете что нормально отправлять изменения и сохранять их на сервере по каждому чиху пользователя? А если он решит отменить изменения?

Здравствуйте, Ocenochka

O> А как можно некорректно изменить данные, которые имеют версию? Два лока сделать одновременно ведь не удасться даже теоретически, на сколько я понимаю.

А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами. Данные у вас лежат в СУБД — любой запрос может помацать их несмотря ни на какие псевдоблокировки. Впрочем это слегка другой вопрос, просто не надейтесь что мой вариант == панацея от всех бед

P.S. Вариант с резервированием рулит когда у вас ресурсов чуть меньше чем клиентов. Если клиентов стабильно толпа, а ресурс используется ограниченное время (не ваш случай) то оптимистические блокировки или "last wins" пожалуй подойдёт лучше.

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

Z>>Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO.
G>Различий гораздо больше.
G>Пример — нужно получить список заказов с адресом клиента и фамилией менеджера, отвественного за заказ.
G>В жирной модели надо загрузить список заказов, для каждого заказа надо загрузить полный объект менеджера и клиента.

Обе модели допускают оптимизацию подобных сценариев. Про непотимальныю работу с БД в рич модели by default я уже писал.

G>Это бред воспаленного сознания.

Культура общения для тебя не главное, как я понял. Если диалог не интересен — продолжай в том же духе, я пойму и забью на него.

G>ER-модели (модели данных) начали применяться гораздо раньше, чем ООП. Стройная модель — как раз отражение модели данных в программе.
G>Причеем между моделью данных и схемой хранения может быть достаточно нетривиальынй маппинг.

Обе модели отражают данные, обе могут делать это нетривиальными маппингами, что сказать-то хотел? Нетривиальный маппинг в тощей модели, скорее вреден, так как способствует persistance ignorance, т.о. лишая тощую модель одного из главных достоинств.

Z>>Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели).
G>Смысл этой фразы для меня остался загадкой.

С тощей моделью логика в БД уживается лучше, это логично ложится в концепцию БД==модель.

G>Практика показывает обратное. На каком-то пороге сложности domain model перестает оправдывать себя.

Т.е. у тебя был случай, когда изза возрастающей сложности пришлось отказаться от DDD? Или какая практика?

Z>>У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель. Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.
G>Это за счет чего достигается? Магией чтоли?
G>И что вообще означает "не позволяет нарушить ни одного бизнес правила", если программа чего-то такого допускает, то это бага.

Различие между программой и моделью не видно? Рич модель не позволяет, а с тонкой можно проделать все что угодно в коде бизнес процессов.

G>Кстати, а что означает "дает максимально полный интерфейс для работы над собой"?

В обеих моделях есть некое ядро, работая с которым нарушить логику невозможно. Интерфейс работы с этим ядром в жирной модели выглядит более богатым, а код самого ядра более компактным. Соответственно проще его верификация.

Z>>Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.
G>Пример такого случая будет?

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

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

G>>ER-модели (модели данных) начали применяться гораздо раньше, чем ООП. Стройная модель — как раз отражение модели данных в программе.
G>>Причеем между моделью данных и схемой хранения может быть достаточно нетривиальынй маппинг.

Z>Обе модели отражают данные, обе могут делать это нетривиальными маппингами, что сказать-то хотел? Нетривиальный маппинг в тощей модели, скорее вреден, так как способствует persistance ignorance, т.о. лишая тощую модель одного из главных достоинств.
И почему же вреден? Примеры будут?

Z>>>Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели).
G>>Смысл этой фразы для меня остался загадкой.
Z>С тощей моделью логика в БД уживается лучше, это логично ложится в концепцию БД==модель.
Это ты сам придумал.

G>>Практика показывает обратное. На каком-то пороге сложности domain model перестает оправдывать себя.
Z>Т.е. у тебя был случай, когда изза возрастающей сложности пришлось отказаться от DDD? Или какая практика?
Был. Я узнав про DDD попытался написать прогу в чисто dddшном. К концу разработки код оброс обилием неDDDшных конструкций, от самого DDD осталось мало. При этом на началном этапе я очень много времени потратил на поддержку именно DDD.

Z>>>У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель. Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.
G>>Это за счет чего достигается? Магией чтоли?
G>>И что вообще означает "не позволяет нарушить ни одного бизнес правила", если программа чего-то такого допускает, то это бага.
Z>Различие между программой и моделью не видно?
Модель (елси мы говорим не об артефакте анализа) — часть программы.

Z>Рич модель не позволяет, а с тонкой можно проделать все что угодно в коде бизнес процессов.
И что?

G>>Кстати, а что означает "дает максимально полный интерфейс для работы над собой"?
Z>В обеих моделях есть некое ядро, работая с которым нарушить логику невозможно. Интерфейс работы с этим ядром в жирной модели выглядит более богатым, а код самого ядра более компактным. Соответственно проще его верификация.
Не надо ударяться в философию.
В стройной модели есть данные и есть методы работы с ними. Никаких "ядер" "интерфейсов" и прочей мути.
Если есть пример, показывающий обратное — можешь привести.

Z>>>Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.
G>>Пример такого случая будет?
Z>Не будет, мне пока хватает тощей, хотя рич модель я проектировал тоже, не сказал бы, что она доставляла мне проблемы своим существованием. Даже если бы такой пример у меня был, его описание потребовало бы за сотню страниц текста, который ты все равно не стал бы читать. Но я убежден, что такие сценарии существуют.
Слепая вера — самое страшное в программировании.

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

Z>>Обе модели отражают данные, обе могут делать это нетривиальными маппингами, что сказать-то хотел? Нетривиальный маппинг в тощей модели, скорее вреден, так как способствует persistance ignorance, т.о. лишая тощую модель одного из главных достоинств.
G>И почему же вреден? Примеры будут?

Это обсуждалось на данном форуме тыщу раз. Воспользуйся поиском, пересказывать лень.

Z>>С тощей моделью логика в БД уживается лучше, это логично ложится в концепцию БД==модель.
G>Это ты сам придумал.

Что лучше уживается или что логично ложится?

G>Я узнав про DDD попытался написать прогу в чисто dddшном. К концу разработки код оброс обилием неDDDшных конструкций, от самого DDD осталось мало. При этом на началном этапе я очень много времени потратил на поддержку именно DDD.

Примеры неDDDшных конструкций в студию.

Z>>Различие между программой и моделью не видно?
G>Модель (елси мы говорим не об артефакте анализа) — часть программы.

Я говорю именно про модель, а не про всю программу. Хотел бы про программу писал бы программа. Зачем вносить путаницу?

Z>>Рич модель не позволяет, а с тонкой можно проделать все что угодно в коде бизнес процессов.
G>И что?

Z>>В обеих моделях есть некое ядро, работая с которым нарушить логику невозможно. Интерфейс работы с этим ядром в жирной модели выглядит более богатым, а код самого ядра более компактным. Соответственно проще его верификация.
G>Не надо ударяться в философию.
G>В стройной модели есть данные и есть методы работы с ними. Никаких "ядер" "интерфейсов" и прочей мути.
G>Если есть пример, показывающий обратное — можешь привести.

Это не философия, если ты не выделяешь подобного ядра — тебе надо быть уверенным во всей программе.

G>Слепая вера — самое страшное в программировании.

Согласен. Я не зря написал убежден.

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

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

O>> однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру.

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

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

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

O> Плюс один — наличие актуальных данных на клиентах. Вообще-то, я согласен, но хочется рассмротреть все варианты пока есть возможность.

наличие более актуальных данных. актуальные они только в БД.

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

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

Z>>>Обе модели отражают данные, обе могут делать это нетривиальными маппингами, что сказать-то хотел? Нетривиальный маппинг в тощей модели, скорее вреден, так как способствует persistance ignorance, т.о. лишая тощую модель одного из главных достоинств.
G>>И почему же вреден? Примеры будут?

Z>Это обсуждалось на данном форуме тыщу раз. Воспользуйся поиском, пересказывать лень.
Я форум уже несколько лет читаю каждый день и нечего подобного вспонить не могу.
Может я чего-то не понял? В каких достоинств лишается стройная модель?

Z>>>С тощей моделью логика в БД уживается лучше, это логично ложится в концепцию БД==модель.
G>>Это ты сам придумал.
Z>Что лучше уживается или что логично ложится?
То что это вообще имеет какой-то смысл в данном обсуждении.

G>>Я узнав про DDD попытался написать прогу в чисто dddшном. К концу разработки код оброс обилием неDDDшных конструкций, от самого DDD осталось мало. При этом на началном этапе я очень много времени потратил на поддержку именно DDD.
Z>Примеры неDDDшных конструкций в студию.
В основном дополнительные классы для работы с произвольными выборками. Не помню уже все давно это было и на делфи.

Z>>>Различие между программой и моделью не видно?
G>>Модель (елси мы говорим не об артефакте анализа) — часть программы.
Z>Я говорю именно про модель, а не про всю программу. Хотел бы про программу писал бы программа. Зачем вносить путаницу?
Еще раз модель — часть программы. Рассматривать модель отдельно от программы смылса нету.
Не бывает модель ценной сама по себе.

Z>>>Рич модель не позволяет, а с тонкой можно проделать все что угодно в коде бизнес процессов.
G>>И что?

Z>>>В обеих моделях есть некое ядро, работая с которым нарушить логику невозможно. Интерфейс работы с этим ядром в жирной модели выглядит более богатым, а код самого ядра более компактным. Соответственно проще его верификация.
G>>Не надо ударяться в философию.
G>>В стройной модели есть данные и есть методы работы с ними. Никаких "ядер" "интерфейсов" и прочей мути.
G>>Если есть пример, показывающий обратное — можешь привести.

Z>Это не философия, если ты не выделяешь подобного ядра — тебе надо быть уверенным во всей программе.
А если бы выделял ядро, то не надо было бы быть уверенным?

Я вообще-то тесты пишу.

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

G>То что это вообще имеет какой-то смысл в данном обсуждении.
ок, проехали.

Z>>Примеры неDDDшных конструкций в студию.
G>В основном дополнительные классы для работы с произвольными выборками. Не помню уже все давно это было и на делфи.

Почему ты решил, что эти кклассы "неDDDшные"? Рич модель не обязана состоять только из персистных классов. Она отличается от тонкой только тем, что допускает логику в персистных, но нигде не говорится об обязательном отсутствии BL в других классах.

G>Еще раз модель — часть программы. Рассматривать модель отдельно от программы смылса нету.
G>Не бывает модель ценной сама по себе.

Z>>Это не философия, если ты не выделяешь подобного ядра — тебе надо быть уверенным во всей программе.
G>А если бы выделял ядро, то не надо было бы быть уверенным?

Это уже пошла философия. Есть критические ошибки в БЛ, которые стоят очень дорого. Есть некое ядро, при корректности которого нарушить БЛ сложно/невозможно. Чем компактнее это ядро, тем легче его поддерживать. Я убежден, что рич модель позволяет сделать такое ядро более компактным и проще поддерживаемым. Правда требует большей квалификации при его дизайне.

Пример из практики, при переводе на клиент-сервер одной из систем сделали из рич модели тощую, руководствуясь примерно теми же мотивами, что и ты декларируешь. Ядро логики мне не удалось изолировать так же хорошо как и в жирной, хотя я проектировал ее на три года позже чем жирную (смею надеяться, что за три года в голове прибавилось ). Реюз кода уменьшился и, как я ни старался, сейчас требуется намного больше знаний о системе для написания новой логики. Сейчас я уже не так уверен, что решение проблем рич модели было бы дороже. И уж точно не сомневаюсь в праве рич моделей на жизнь.

G>Я вообще-то тесты пишу.

Дада, и в твоих программах больше нет ни одной ошибки. Рич модель несоместима с тестами чтоли?

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

O>>Не очень понимаю как отслеживать изменения. Допустим на клиенте грид с коллекцией объектов. При редактировании в отдельную коллекцию складывать отредактированные объекты? А как порядок редактирования учитывать?
MC>Вы видимо невнимательно прочитали тему. Либо реализовывать флаг IsDirty в самом бизнес-объекте (базовом классе), либо использовать Wrapper, который будет отслеживать изменения обертываемого объекта и реализовывать флаг IsDirty. Если нужно учитывать порядок редактирования — это отдельная задача, но лично мне никогда не нужно было учитывать порядок редактирования.

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

MC>Вы уверены что вы заранее не усложняете задачу зачем-то?

Ну может слегка Не известно же что завтра заказчику в голову ударит, вот и пытаюсь импровизировать.

O>>>> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
MC>>>Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx

Автор: MozgC
Дата: 21.04.09

O>>Прочитал. Понял не много и легче не стало.
MC>Может стоит еще раз внимательно прочитать? Я серьезно.

Прочитал. Понял не на много больше, чем после первого прочетния.

O>>Врапперы над сущностями и их коллекциями — это круто. Не совсем представляю как это будет в случае с несколькими клиентами.
MC>Видимо у каждого клиента будет своя коллекция обернутых объектов.

Ага, теперь понятно.

O>>DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
MC>В принципе датасеты вариант, но лично мне кажется что они провоцируют дублирование логики, а так же вынос логики в presentation. К тому же нетипизированные датасеты неудобны отсутствием типизации, а типизированные датасеты дают мало контроля, т.к. все генерируется и перегенерируется автоматически.

Вот вот, поэтому и не хочу с ними связываться.

O>>А последовательность изменений не учитывать? Если пятая операция из 10 не прошла, то, на мой взгляд, логично откатить все 10. Соответственно, пользователю прдется переделывать все 10.
MC>Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.

Хороший варант, только усложняет обработку ошибок, хотя может и не так сильно как мне кажется. Спасибо.

MC>Если же вы про облом операции именно по причине коллизии, то тут надо сначала знать, что должно происходить в случае коллизии? Может просто молча должны записаться изменения пользователя (на мой взгляд зачастую это вполне допустимо), или же надо сообщить пользователю о том что в БД уже етсь измененная версия объекта и спросить хочет ли он ее перезаписать? Или же надо перечитать (или просто отдельно показать) измененный объект из БД? Или надо все перечитать? Это вы должны сначала вместе с экспертами предметной области решить как должна вести себя система.

Вот это мне и не нравится, ибо сложности предметной области в данном случае могут вылиться в большой объем логики обработки таких ошибок. Подозреваю, что проще лочить объекты перед началом редактирования.

O>>>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>>>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
MC>>>Это просто неправильно так делать.
O>>Не правильно делать категоричные заявления без аргументов Ясно, что производительность и отзывчивость могут пострадать, если клиентов будет много, а сервер далеко, но есть подозрение, что дело не в этом.
MC>И в этом тоже. Вы вообще искренне считаете что нормально отправлять изменения и сохранять их на сервере по каждому чиху пользователя? А если он решит отменить изменения?

Изменение решения — это уже достаточный аргумент. Опять спасибо.

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

G>>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
O>> Как не надо? А как об изменении смогут узнать другие клиенты?
G>Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать?

Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.

O>>>>>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
G>>>>>В таком решении ты найдешь тысячи граблей, с которыми будешь долго бороться.
O>>>> Пока не вижу у нас единого взгляда на это решение, учитывая заданные мне вопросы.
G>>>А ты подробнее распиши задачу и покажи свои наработки.
O>> Задача занимает сейчас около 100 стр. при этом я не могу понять что даст раскрытие ньюансов конкретной предметной области. Премер я уже приводил. Наработки еще не закончены, однако есть четкое представление архитектуры.
G>Может дать очень много потому что единственное что сейчас видят люди на форуме — это твое трактование предметной области.

И для них этого вполне достаточно, судя по многим адекватным коментариям, которые я понимаю.

G>>>Создавать сферическую архитектуру в вакууме не получится.
O>> Однако, глядя на ваши ответы, я считаю, что у вас это вполне получается Без обид.
O>>Просто я не вижу у вас понимания решения N1.
G>Это у тебя нету понимания решения N1, я такие решения в разных видах уже делал.

С тонкой domain model делал?

O>>То, что вы пробовали городить dataset'ы — это я уже выяснил
G>Мимо. Как раз решения с dataset я предпочитаю не городить, я один раз начал такое делать и быстро отказался.

А как делал?

O>>и то что опыта с orm и domain model не имели то же выяснил
G>Совсем мимо. С orm работаю постоянно и даже свой писал.
G>Хреновый из тебя телепат.

Я и не претендовал Жду доказательств своей хреновости в виде ответов на вопросы

O>>>>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>>>>Оба неадекваты на 99%
O>>>> Предлагайте!
G>>>Сделать кнопку Save, по которой сохранять изменения.
G>>>Далее 3 варианта:
G>>>1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)
O>> В задаче сказано, что БД — одна.
G>И что? SQL CE — несколько dll и больше ничего не надо

Я знаю, что такое SQL CE и работал с ней, однако, синхронизация должна быть чаще чем раз в минуту. Городить для этого репликацию из локальных БД... Синхронизацию руками проводить? Чем локальный кэш NHibernate хуже, чем локальная БД?

G>>>2)Написать кучу сервисов и DTO
O>> Это зачем и к чему?
G>Ко всему. Если клиент не толстый, то лучше увеличить гранулярность обращения к серверу. Для этого потребуется метод сервиса и вероятнее всего DTO.

Клиент толстый.

G>>>3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services
O>> Каким образом?
G>Создть модель в EF дизайнере, создать сервис ADO.NET, сделать клиент.

Не пробовал EF, слышал негативные отзывы, как работает — не представляю. В чем преимущества?

O>> Есть четкая задача, которую я обозначил дважды, повторю еще раз: есть два клиента, работающих с общей БД. Как реализовать их работу при отсутствии коллизий?
G>Наверное при наличии коллизий. Варианта как всегда два:
G>1)пессимистичная блокировка — когда данные могут меняться только одним клиентом в один момент времени.
G>2)оптимистичная блокировка, когда оба редактируют данные, если при попытке сорхнанить версии не сопадают — исправить конфликт и попытаться еще раз.
G>Оптимистичная блокировка на самом деле блокировкой не является, несмотря на назание, и в некоторых случаях не работает.

Почему не работает? У же который раз пишут, что может не работать, однако я не представляю как это возможно в случае наличия версии в каждой сущности и транзакционной БД.

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

O>> А как можно некорректно изменить данные, которые имеют версию? Два лока сделать одновременно ведь не удасться даже теоретически, на сколько я понимаю.
S>А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами.

А если потребуется, от что? Нельзя будет учесть версию объекта, или транзакционность БД как-то отменится?

S>Данные у вас лежат в СУБД — любой запрос может помацать их несмотря ни на какие псевдоблокировки.

Раскажите, наконец, каким образом? Например, есть объект "клиент" у него есть свойство "счет". Объект имеет версию, лежит в БД. Дав клиента забирает его из БД, изменяют и пытаются положить обратно предварительно проверив версию объекта. Как возможна коллизая, эсли "помацать" — это коллизия ?

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

M>Прежде всего, вариант N2 следует отмести как нереализуемый -- уж очень много всяких косяков там вылезает: начиная от проблем с проксями NHibernate и заканчивая сбоями сети. Кроме того, работа по сети в таком случае выльется в безобразные тормоза на клиенте.

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

M>Итак, остается вариант №1, которым обычно и пользуются при написании 3хзвенок.
M>Чтобы претворить его в жизнь, нужно:
M>1) Определиться с генератором DTO: будет он или вы сами будете гонять отсоединенные объекты (DTO можно готовить и руками, но лучше взять что-либо типа otis lib);

Не понял, что подразумевается под генератором DTO. Пока решено гнять тонкие бизнес-объекты, а в тонких местах — DTO.
Сейчас начинаю понимать, что наличие единого сервера не нужно, поэтому клиенты будут просто получать из БД (от NHibernate) бизнес объекты и лочить/апдейтить их самостоятельно, а не через сервер. Соответственно, необходимость в DTO отпадает, как я понимаю.

M>2) Кнопка Save в вашем случае -- отличное решение; нужно только определиться с сеансами редактирования (т.е. где эти кнопки будут находиться и каковы будут участки, работа на которых идет от сохранения до сохранения;

Согласен, это не так сложно в моем случае.

M>3) Определиться с тем, как вы будете решать конфликты одновременного обновления: пессимистический вариант и оптимистический, соотственно.
M>В случае пессимистического вы не допускаете конфликтов -- при помощи транзакций БД(хардкор, но иногда допустим или на уровне бизнес-транзакций (т.н. conversation), помечая и блокируя бизнес-объекты , находящиеся в редактировании;
M>В случае оптимистического варианта вы решаете разруливать конфликты одновременного обновления по факту обнаружения таких конфликтов. Вариантов здесь а)затирать старые изменения (игнорируем конфликт) б) не давать затирать при помощи проверки версии (NHibernate вам в помощь) и просить пользователя внести вторично правку в устаревшие данные в) реализовать стратегию merge данных, если данные могут быть объединены без логического конфликта
M>Ничего не мешает сочетать эти варианты, согласуясь с другими критериями.

Да, решено уже по мере надобности сочитать разные блокировки. Пугает только, что это может вылиться в большой объем логики обработки исключений конфликтов.

M>Да, и ответ на ваш вопрос -- NHibernate сам умеет поддерживать версии объекта, так что коллизий не будет; если вам интересно, я напишу следующим сообщением, почему описанная вами ситуация не случится.

Я и сам догадываюсь, но все равно напишите, т.к. я не знаю как это выразить словами. То, что NHibernate поддерживает <version> я знал, но использовать не приходилось и смутно представляю реализацию в sql. Видимо при апдейте идет проверка, что свойство version = currentVersion.

M>4) Определитесь со стратегией кеша и провайдером кеша (не все из них поддерживают блокировку объектов!). Со своей стороны могу порекомендовать SharedCache.net, ибо пробовал, понравилось; memcached не пробовал, но буду в след. проекте;

Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
том же кэше говорим?

M>5) Определиться со стратегией выработки Id(PK) для бизнес-объектов -- некоторые, например, identity, плохо совместимы с NHibernate 2nd level cache.

Пока всегда хватало сурогатного Int64.

M>Если заинтересовало, пишите, продолжим обсуждение трудностей и подводных камней.

Заинтересовало, давайте продолжать.

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

O>>>DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
MC>>В принципе датасеты вариант, но лично мне кажется что они провоцируют дублирование логики, а так же вынос логики в presentation. К тому же нетипизированные датасеты неудобны отсутствием типизации, а типизированные датасеты дают мало контроля, т.к. все генерируется и перегенерируется автоматически.
O> Вот вот, поэтому и не хочу с ними связываться.
Кстати для опыта можно и что-нибудь сделать с ними, выявите для себя удобства и недостатки.

MC>>Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
O> Хороший варант, только усложняет обработку ошибок, хотя может и не так сильно как мне кажется. Спасибо.
Чем усложняет? Можно подробнее?

O> Вот это мне и не нравится, ибо сложности предметной области в данном случае могут вылиться в большой объем логики обработки таких ошибок. Подозреваю, что проще лочить объекты перед началом редактирования.
Не знаю, я не специалист в этой теме. Давайте лучше не будем говорить абстрактно, а рассмотрим пару примеров. Приведите пару конкретных реальных примеров из вашей задачи, и думаю что знающие люди предложат решения для этих конкретных случаев. Думаю что так от беседы будет больше практической пользы.

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

MC>>>Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
O>> Хороший варант, только усложняет обработку ошибок, хотя может и не так сильно как мне кажется. Спасибо.
MC>Чем усложняет? Можно подробнее?

В случае оптимистических блокировок (разруливание по факту обновления, а не перед) модет оказаться необходимым выяснять зависимости меду объектами, чтобы делать мержи, откаты или накаты, это будет зависеть от предметной области, которая может быть доволно сложной.

O>> Вот это мне и не нравится, ибо сложности предметной области в данном случае могут вылиться в большой объем логики обработки таких ошибок. Подозреваю, что проще лочить объекты перед началом редактирования.
MC>Не знаю, я не специалист в этой теме. Давайте лучше не будем говорить абстрактно, а рассмотрим пару примеров. Приведите пару конкретных реальных примеров из вашей задачи, и думаю что знающие люди предложат решения для этих конкретных случаев. Думаю что так от беседы будет больше практической пользы.

Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.

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

O> Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.

Чем этот пример отличается от простого редактирования клиентов без счетов и договоров (это я чтобы избавить пример от возможно ненужных зависимостей)?

Как вы сами считаете должна вести себя система если при сохранении клиента оказывается что в БД уже есть более новая версия клиента?
Или вы считаете что нельзя редактировать клиента одновременно на разных машинах? Если нельзя редактировать клиента на разных машинах, то когда ставить блокировку? И что если оператор уйдет на обед?

Т.е. сначала надо определиться с этими вопросами. Может кто из более опытных участников посоветует наиболее подходящие решения для таких сценариев.

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

O>> Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.
MC>Чем этот пример отличается от простого редактирования клиентов без счетов и договоров (это я чтобы избавить пример от возможно ненужных зависимостей)?

В том то и дело, что записимости возможно нужны.

MC>Как вы сами считаете должна вести себя система если при сохранении клиента оказывается что в БД уже есть более новая версия клиента?

В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.

MC>Или вы считаете что нельзя редактировать клиента одновременно на разных машинах?

Наоборот, я только и делаю, что везде пишу про проблемы с этим связанные

MC>И что если оператор уйдет на обед?

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

MC>Т.е. сначала надо определиться с этими вопросами. Может кто из более опытных участников посоветует наиболее подходящие решения для таких сценариев.

Только на них и надеюсь

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

O> В том то и дело, что записимости возможно нужны.
Подробнее? Как они влияют на пример?

O> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.
Или можете ответить "я не знаю как лучше, подскажите"?

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

O> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>том же кэше говорим?

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

O> Пока всегда хватало сурогатного Int64.

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

Ziaw, а можно прокомментировать в чем вы так несогласны?

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

O>> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
MC>Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.

Конкретная стратегия зависит именно от конкретного объекта который вызвал конфликт. От логики предметной области. Она должна диктовать что в данном случае следует сделать. Какая конкретика нужна еще? Как пользователю удобнее так и следует сделать, лишь бы логику не нарушить.

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

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

O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>>том же кэше говорим?

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

Товарищ Ziaw, не запутывайте ) "Их гораздо больше, чем 2" можно трактовать весьма по-разному
Уровней кеша в NHibernate 2 -- session object и 2nd level cache. Второй уровень -- реализован по типу plug-in: вы подставляете тот провайдер, который нужен. NativeHash, SysCache, SharedCache, Bamboo.Prevalence, memcached, NCache, OSCache -- это разнообразные провайдеры, выбирайте тот, который нужен, и вперед. Prevalence, например, умеет персиститься на диск, SharedCache -- реплицироваться между машинами, а NCache -- хороший, но его основные вкусности начинаются только в платной версии )

O>> Пока всегда хватало сурогатного Int64.
Z>Вам говорят о его генерации, identity это то, чего следует избегать. Используйте гуиды на худой конец, раз MSSQL не имеет нормального сиквенса.

Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

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

M>Товарищ Ziaw, не запутывайте ) "Их гораздо больше, чем 2" можно трактовать весьма по-разному

Сорри ) Не совсем однозначно высказался. Следует читать — "разновиднойстей кеша 2го уровня для NH гораздо больше чем 2".

M>Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

Интересно, а можно линк на эту тему?

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

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

O> Не понял, что подразумевается под генератором DTO. Пока решено гнять тонкие бизнес-объекты, а в тонких местах — DTO.
Если объекты таки будут толстыми, то писать для них вручную DTO и код Rich Object <-> DTO затруднительно. Otislib -- это object-2-object mapper, который позволяет задать, как трансформировать объекты один в другой, и не писать вручную код, который должен будет это делать.

O> Сейчас начинаю понимать, что наличие единого сервера не нужно, поэтому клиенты будут просто получать из БД (от NHibernate) бизнес объекты и лочить/апдейтить их самостоятельно, а не через сервер. Соответственно, необходимость в DTO отпадает, как я понимаю.
Хм, интересно, как вы в отсутствии единого сервера организуете общий кэш? У вас на каждом клиенте планируется иметь фабрику сессий NHibernate?

M>>3) Определиться с тем, как вы будете решать конфликты одновременного обновления: пессимистический вариант и оптимистический, соотственно.
M>>В случае пессимистического вы не допускаете конфликтов -- при помощи транзакций БД(хардкор, но иногда допустим=)) или на уровне бизнес-транзакций (т.н. conversation), помечая и блокируя бизнес-объекты , находящиеся в редактировании;
M>>В случае оптимистического варианта вы решаете разруливать конфликты одновременного обновления по факту обнаружения таких конфликтов. Вариантов здесь а)затирать старые изменения (игнорируем конфликт) б) не давать затирать при помощи проверки версии (NHibernate вам в помощь) и просить пользователя внести вторично правку в устаревшие данные в) реализовать стратегию merge данных, если данные могут быть объединены без логического конфликта
M>>Ничего не мешает сочетать эти варианты, согласуясь с другими критериями.

O> Да, решено уже по мере надобности сочетать разные блокировки. Пугает только, что это может вылиться в большой объем логики обработки исключений конфликтов.
Воспользуйтесь PostSharp для разделения логики обработки конфликтов и остальной логики. Я пользуюсь AOP из Spring.NET, но принцип тот же.

O> Я и сам догадываюсь, но все равно напишите, т.к. я не знаю как это выразить словами. То, что NHibernate поддерживает <version> я знал, но использовать не приходилось и смутно представляю реализацию в sql. Видимо при апдейте идет проверка, что свойство version = currentVersion.
Примерно так, как вы сказали. Если сконфигурирована проверка version (timestamp), то NHibernate при сохранении проверяет, что версия в БД -- та же, что и в объекте. Если сконфигурирована select-проверка -- будет выполнен select на предмет того, чтобы non-dirty поля совпадали. При использовании в кластере timestamp лучше не использовать.

O> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>том же кэше говорим?
O> Пока всегда хватало сурогатного Int64.
Ответил ниже, в комменте после Ziaw

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

O>> В том то и дело, что записимости возможно нужны.
MC>Подробнее? Как они влияют на пример?
O>> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
MC>Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.
MC>Или можете ответить "я не знаю как лучше, подскажите"?

Тот же пример с клиентами и договорами, которых выгрузили на клиента, изменили, а при апдейте выяснилось, что клиент, или один из его контрактов изменен. Теперь предположим, что в соответствии с предметной областью, в таком случае возможны следующие варианты:
1. Изменились не существенные данные клиента, например, его сесейный статус — в этом случае можно апдейтить.
2. Изменились важные данные, например,
— количество контрактов,
— данные контрактов,
— количество контрактов.
В каждом из этих случаев возможна своя логика для определения того — накатывать или откатывать.

Здравствуйте, Ziaw, Вы писали:
O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и том же кэше говорим?
Z>Вы говорите об одном и том же кеше, кеше второго уровня.
Z>Их гораздо больше чем два,

В NHibernate больше? Интересно.

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

А почему не использовать на каждом клиенте свой кэш?

O>> Пока всегда хватало сурогатного Int64.
Z>Вам говорят о его генерации, identity это то, чего следует избегать. Используйте гуиды на худой конец, раз MSSQL не имеет нормального сиквенса.

А я о чем? Почему следует избегать identity? Без него вроде вообще никак. Гуиды слишком велики и бест практисы их не советуют.
Что подразумевается под "нормальным сиквенсом"?

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

M>>Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

Z>Интересно, а можно линк на эту тему?

Да. Там 9 страниц, со второй начинается интересное: "The Cost of GUIDs as Primary Keys", http://www.informit.com/articles/article.aspx?p=25862

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

O>> Не понял, что подразумевается под генератором DTO. Пока решено гнять тонкие бизнес-объекты, а в тонких местах — DTO.
M>Если объекты таки будут толстыми, то писать для них вручную DTO и код Rich Object <-> DTO затруднительно. Otislib -- это object-2-object mapper, который позволяет задать, как трансформировать объекты один в другой, и не писать вручную код, который должен будет это делать.

А, ясно. Объекты будут тонкими, надеюсь вообще избежать DTO, но знать что это решаемо на будующее очень полезно, спасибо.

O>> Сейчас начинаю понимать, что наличие единого сервера не нужно, поэтому клиенты будут просто получать из БД (от NHibernate) бизнес объекты и лочить/апдейтить их самостоятельно, а не через сервер. Соответственно, необходимость в DTO отпадает, как я понимаю.
M>Хм, интересно, как вы в отсутствии единого сервера организуете общий кэш? У вас на каждом клиенте планируется иметь фабрику сессий NHibernate?

Если под сервером понимается сервер приложения, то по возможности хотелось бы его избежать — вроде возможность есть. А в чем проблема иметь на каждом клиенте свою фабрику и свой кэш? При insert/update/delete все равно в БД лезть, а на чтение кэш может пригодится; в случае же коллизий при обновлении устаревших данных (в оптимистической блокировке) спасет версионность объектов.
В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.

O>> Да, решено уже по мере надобности сочетать разные блокировки. Пугает только, что это может вылиться в большой объем логики обработки исключений конфликтов.
M>Воспользуйтесь PostSharp для разделения логики обработки конфликтов и остальной логики. Я пользуюсь AOP из Spring.NET, но принцип тот же.

О, я то же использую Spring.NET, однако до AOP'а еще дело особо не доходило, кроме примитивных моментов.
Спасибо, это действительно может помочь при отделении логики основной работы от логики обработки конфликтных ситуаций.

O>> Я и сам догадываюсь, но все равно напишите, т.к. я не знаю как это выразить словами. То, что NHibernate поддерживает <version> я знал, но использовать не приходилось и смутно представляю реализацию в sql. Видимо при апдейте идет проверка, что свойство version = currentVersion.
M>Примерно так, как вы сказали. Если сконфигурирована проверка version (timestamp), то NHibernate при сохранении проверяет, что версия в БД -- та же, что и в объекте. Если сконфигурирована select-проверка -- будет выполнен select на предмет того, чтобы non-dirty поля совпадали. При использовании в кластере timestamp лучше не использовать.

Про кластер не понял. Что предпоолагается использовать в кластере, БД? Я пока этих механизмов не представляю. К тому же вроде постепенно появляется возможность "виртуализировать" БД на нескольких машинах в виде одной... хотя эта тема мне пока вообще мало знакома.

O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>>том же кэше говорим?
O>> Пока всегда хватало сурогатного Int64.
M>Ответил ниже, в комменте после Ziaw

Ага, спасибо, очень познавательно.


Пока что вы единственный, с кем у меня совпадает мнение на счет инструментов.
Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?

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

Z>Конкретная стратегия зависит именно от конкретного объекта который вызвал конфликт. От логики предметной области. Она должна диктовать что в данном случае следует сделать.
Ага, я в курсе, я и хотел чтобы автор привел эту логику предметной области. С чем не согласны то?

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

O> Если под сервером понимается сервер приложения, то по возможности хотелось бы его избежать — вроде возможность есть. А в чем проблема иметь на каждом клиенте свою фабрику и свой кэш? При insert/update/delete все равно в БД лезть, а на чтение кэш может пригодится; в случае же коллизий при обновлении устаревших данных (в оптимистической блокировке) спасет версионность объектов.
O> В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.
Это уже мой заскок; я что-то не могу отделаться от того, что у вас 3х-звенка ) а у Вас -- обычное клиент-серверное, где сервер -- БД

O> Про кластер не понял. Что предпоолагается использовать в кластере, БД? Я пока этих механизмов не представляю. К тому же вроде постепенно появляется возможность "виртуализировать" БД на нескольких машинах в виде одной... хотя эта тема мне пока вообще мало знакома.
Имелся в виду кластер серверов приложений. Однако — вы решили, что у вас его нет. Нет сервера, нет проблем.

O> Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?

И приходилось, и участвую. На текущем месте работы 2хзвенку не застал (работал раньше, в основном), но с 3х-звенкой и толстым клиентом пришлось повозиться и вожусь до сих пор. Счас тут используется свой маппер, и так как приложение ориентировано на данные, да еще и с динамической схемой, он -- с особенностями (метаданные хранятся в БД, например) -- не то чтобы ОРМ, скорее Data2Data Mapper, но сойдет. Система старая и кривая -- легковесный и дешевый конкурент SAP MDM, мегатонны кода, постепенно отмирает. Характеристики -- 50G данных, 300-600 одновременно работающих statefull пользователей, куча опций с данными, самописное все, вплоть до сессий пользователя =) Наследие такое. Есть модуль интеграции с XI/SAP, примитивные отчеты, система диагностики и администрирования. Из-за специфики задач (данные разных пользователей пересекаются часто) использовалась в основном пессимистическая блокировка с таймаутами и прочими "вкусняшками".

На предыдущем месте работы, занимался геоданными и распределенными БД и серверами для них (может быть, слышали про ArcGIS).

Сейчас в разработке -- тоже многозвенка с UI на Silverlight, на сервере приложений -- Spring.NET, NHibernate, memcached, DSLки на Boo. Пытаемся сделать клиент максимально тонким, но с преимуществами толстого -- такими, например, как некоторая логика на клиенте и локальный персистентный кеш данных. Хотим перейти на оптимистические блокировки и более "объектную" модель хранилища. Думаю, осилим в этом году )

Как-то так. Извините, если неинтересно получилось -- про себя плохо получается рассказывать

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

O>> В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.
M>Это уже мой заскок; я что-то не могу отделаться от того, что у вас 3х-звенка ) а у Вас -- обычное клиент-серверное, где сервер -- БД

Это наверно я ввел в заблуждение темой топика

O>> Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?
M>И приходилось, и участвую. На текущем месте работы 2хзвенку не застал (работал раньше, в основном), но с 3х-звенкой и толстым клиентом пришлось повозиться и вожусь до сих пор. Счас тут используется свой маппер, и так как приложение ориентировано на данные, да еще и с динамической схемой, он -- с особенностями (метаданные хранятся в БД, например) -- не то чтобы ОРМ, скорее Data2Data Mapper, но сойдет. Система старая и кривая -- легковесный и дешевый конкурент SAP MDM, мегатонны кода, постепенно отмирает. Характеристики -- 50G данных, 300-600 одновременно работающих statefull пользователей, куча опций с данными, самописное все, вплоть до сессий пользователя =) Наследие такое. Есть модуль интеграции с XI/SAP, примитивные отчеты, система диагностики и администрирования. Из-за специфики задач (данные разных пользователей пересекаются часто) использовалась в основном пессимистическая блокировка с таймаутами и прочими "вкусняшками".
M>На предыдущем месте работы, занимался геоданными и распределенными БД и серверами для них (может быть, слышали про ArcGIS).
M>Сейчас в разработке -- тоже многозвенка с UI на Silverlight, на сервере приложений -- Spring.NET, NHibernate, memcached, DSLки на Boo. Пытаемся сделать клиент максимально тонким, но с преимуществами толстого -- такими, например, как некоторая логика на клиенте и локальный персистентный кеш данных. Хотим перейти на оптимистические блокировки и более "объектную" модель хранилища. Думаю, осилим в этом году )
M>Как-то так. Извините, если неинтересно получилось -- про себя плохо получается рассказывать

Интересно, а главное, что у меня такого опыта нет, но скорее всего предстоит ) Если что по архитектуре буду консультироваться, если не против, потому как любителей Spring.NET + NHibernate не много видел ( Есть еще на этом форуме один любитель — Нахлобуч, но его застать так же трудно.

Мне вот сейчас интересно стало как общий случай трехзвенки реализуется. Логика работы с данными выносится на сервер, а на каждом клиенте дополнительно своя небольшая логика? Т.е. алгоритм примерно такой? :
1. Клиент запрашивает у сервера нужные объекты через сервис.
2. Сервер получает объекты из БД и отдает на клиента, сериализуя.
3. Клиент работает с объектами через свою логику, параллельно обращаясь на сервер по необходимости (что бы залочить например объект)
4. Клиент возвращает объекты серверу с просьбой сохранить состояние, в случае проблем дополнительная логика на клиенте разруливает проблемы.
А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
Надеюсь понятно излагаю )

Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
Что в 2-х звенке, что в 3-х — неужели только логи?

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

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

O> Мне вот сейчас интересно стало как общий случай трехзвенки реализуется. Логика работы с данными выносится на сервер, а на каждом клиенте дополнительно своя небольшая логика? Т.е. алгоритм примерно такой? :
O> 1. Клиент запрашивает у сервера нужные объекты через сервис.
O> 2. Сервер получает объекты из БД и отдает на клиента, сериализуя.
O> 3. Клиент работает с объектами через свою логику, параллельно обращаясь на сервер по необходимости (что бы залочить например объект)
O> 4. Клиент возвращает объекты серверу с просьбой сохранить состояние, в случае проблем дополнительная логика на клиенте разруливает проблемы.
O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
O> Надеюсь понятно излагаю )

Излагаете понятно, и алгоритм примерно такой.Но нюансов много: пп. 2 и 3 могут быть оба, могут быть совмещены или 3 не вызываться, с этим все ясно, думаю. Лочатся так же не только сами объекты, но и целые их логические наборы (все то, что вовлекается в UnitOfWork, например). Чтобы не было неожиданных обновлений (юзеры пугаются=)) перед погружение "вглубь" данных иногда приходится делать снэпшоты наборов данных -- они тоже хранятся на сервере. Скажем, при поиске в большом массиве объектов по условию найдено 1000 объектов, размещенных в UI на 50 страницах. При редактировании записи №342 так, что она больше не попадает под условие и листании набора найденных объектов, хотелось бы, чтобы запись по-прежнему осталась в наборе.
Ну, сервис, через который объекты запрашиваются у сервера, у нас -- WebService. Не спрашивайте почему так, тянется еще с fw 1.1 =). Основной критерий был -- обеспечить транспорт через http + удаленный мониторинг состояния и версий.

O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
Все зависит от того, насколько клиент "тонкий". Если это web-приложение, то да -- вся логика лежит на сервере. Так у нас устроен сервис развертывания обновлений, например.

O> Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
O> Что в 2-х звенке, что в 3-х — неужели только логи?
У нас в основном блокировки объектов средствами бизнес-логики (реестр с пометками, что такой-то физический или логический объект редактируется). Для некоторых объектов разрешено только эксклюзивное редактирование, для некоторых -- совместное. При сохранении происходит merge данных (скажем, если 1 пользователь отредактировал описание, а другой -- приаттачил документ, то нет смысла откатывать, можно безболезненно смержить) или отказ с уведомлением одного из пользователей; в зависимости от полномочий он имеет право только повторить редактирование или даже перетереть изменения другого. Раньше куча логики была в БД (опять же, исторически сложилось, что мы мигрировали на 3хзвенку с 2хзвенки, да еще и с с++builder --> c#, а там было много кода в БД на T-SQL), счас постепенно сумели от этого избавиться.

Или вы про какие-то другие ошибочные состояния говорите?

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


Все поскипаное понял, спасибо.

M>Или вы про какие-то другие ошибочные состояния говорите?

Да, я имел ввиду состояния, нарущающие бизнес-логику, например, в БД у клиента хранятся записи, что он был в одно и то же время в разных местах или что-нибудь такое, причем повторить такое не получается. Обычно можно строить предположения и проверять их по очереди, зная архитектуру, но это часто долго, а иногда и придумать что-то сложно. Я представляю, что только по логам, в которые писать все опериции над объектами и соответственно идентификаторы объектов. Но лог писать на каждое действие — это несколько бъет по производительности, а если клиент удаленный, то все еще хуже т.к. придется просить клиента, чтобы он логи прислал, или делать механизм выгрузки логов... в общем не ясно какие механизмы применять в случае обнаружения ошибочных данных в БД.

есть проблема: коллизии
есть инструменты: навернуть, откатать, смеждить и т.д.
пишите что является критерием выбора инструмента: — самый простой пример критерия — это решение проблемы, если в результате использования этого критерия все равно есть несколько инструментод — добавляете допольнительные критерии: скорость, или возможность сопровождения и т.д.
теперь возникает вопрос — что является решением вашей проблемы. а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

поведение системы зависит от конкретных требований заказчика, т.е. если рассуждать абстракто, то можно сделать и так, а можно сделать и эдак. вот по этому ребята, которые вам пытаются помочь советом, и спрашивают о конкретных примерах поведения системы, чтобы понять какой интсрумент вам посоветовать. ответить "я не знаю как лучше, подскажите"?

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

O> Расскажите это заказчику, к которому будут идти недовольные клиенты
насколько я понимаю, заказчик именно к вам и обратился потому, что именно вы и являетесь специалистом в реализации, а не он... по этому именно на вас как на разработчике( специалисте в реализации) лежит ответсвенность за успешную реализацию проекта. клиент всегда имеет свое видение, но его видение базируется на его опыте, на его багаже заний в данной области — у вас как у исполнителя этот багаж должен быть больше. по этому при реализации проекта ваше мнение имеет довольно высокий приоритет — я хочу сказать, что убеждайте вашего клиента и не давайте ему вами рулить как он этого хочет. потму что ответ держать в любом случае вам как исполнителю... и аргументы типа ну вы же сами говорили как нужно в последствии не конают, потому как аргумент заказчика простой — а кто из нас специалист ?

(вы — это абстракция канторы, или IT отдела если в рамках канторы работаете)

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

G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
не понял — что она сосет ? человеческие ресурсы на реализацию? системные ресурсы сервера ?
как на меня любой архитектурный стиль, трезвенка, SOA и т.д. привносит свои плюсы и минусы, и в результате выбор — это компромис... необходимо только составить критерии выбора.

G>И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.
да это правда — хуже не придумаешь... такое решение очень плохо сказывается на производитлеьности, масштабируемости системы... я сомневаюсь что кто-то захочет воплотить такое решение по собственной воле.

O>> Решение N2:
O>> Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
O>> Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать.
O>> Проблемы (и вопросы) решения N2:
O>> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O>> 2. как работать с временем жизни объектов?
O>> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O>> 4. будут ли маршалиться NHibernatе'овские прокси?
G>Это худший вариант развития событий.
G>1)На любое дергание объекта придется бегать на сервер
G>2)Все изменения надо передавать клиентам
G>3)Проблемы с контролем времени жизни
.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.


O>> Воообще, интересуют любые решения практикующих разработчиков

самое простое что приходит в голову это создание несколко представлений для одной модели. где контроллер получая изменения модели и оповещает представления об изменениях, или в зависомости от клиента и требований не оповещает. а вообще без конкретных примеров поведения как я уже писал выше проблема имеет два решения, первое:или вы лочите объект и делаете изменения и разлочиваете, его при этом даете другим клиентам возможность читать данные, но не изменять их. второе:или вы даете возможность нескольким клиентам брать данные с возможностью изменений в этом слечае вам придется решать проблемы с отслеживанием изменений и соотвественно при необходимости мерджем данных...
сюда в зависимости от требований и критичности можно добавить нотификацию об изменениях и возможности редактировании... кстати пример первого поведения реализован в ворде, а в VSS реализованы оба подхода...

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

O>> Расскажите это заказчику, к которому будут идти недовольные клиенты
VPV>насколько я понимаю, заказчик именно к вам и обратился потому, что именно вы и являетесь специалистом в реализации, а не он... по этому именно на вас как на разработчике( специалисте в реализации) лежит ответсвенность за успешную реализацию проекта. клиент всегда имеет свое видение, но его видение базируется на его опыте, на его багаже заний в данной области — у вас как у исполнителя этот багаж должен быть больше. по этому при реализации проекта ваше мнение имеет довольно высокий приоритет — я хочу сказать, что убеждайте вашего клиента и не давайте ему вами рулить как он этого хочет. потму что ответ держать в любом случае вам как исполнителю... и аргументы типа ну вы же сами говорили как нужно в последствии не конают, потому как аргумент заказчика простой — а кто из нас специалист ?

Это понятно

VPV>(вы — это абстракция канторы, или IT отдела если в рамках канторы работаете)

Я — пока разработчик и соархитектор за зарплату На себя ответственность пока брать не могу из-за опыта, иначе бы тут вопросы не задавал

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

VPV>есть проблема: коллизии
VPV>есть инструменты: навернуть, откатать, смеждить и т.д.
VPV>пишите что является критерием выбора инструмента: — самый простой пример критерия — это решение проблемы, если в результате использования этого критерия все равно есть несколько инструментод — добавляете допольнительные критерии: скорость, или возможность сопровождения и т.д.
VPV>теперь возникает вопрос — что является решением вашей проблемы.

Решением моей проблемы является архитектура, которую на каждое новое требование заказчика не надо будет сильно переписывать.

VPV>а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

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

VPV>поведение системы зависит от конкретных требований заказчика, т.е. если рассуждать абстракто, то можно сделать и так, а можно сделать и эдак.

Вот мне и интересно: как именно так и этак.

VPV>вот по этому ребята, которые вам пытаются помочь советом, и спрашивают о конкретных примерах поведения системы, чтобы понять какой интсрумент вам посоветовать. ответить "я не знаю как лучше, подскажите"?

Есть ребята, которые отвечают не спрашивая и отвечают по делу, так что я понимаю и остаюсь удовлетворенным ответами.

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

G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
VPV>не понял — что она сосет ? человеческие ресурсы на реализацию? системные ресурсы сервера ?
VPV>как на меня любой архитектурный стиль, трезвенка, SOA и т.д. привносит свои плюсы и минусы, и в результате выбор — это компромис... необходимо только составить критерии выбора.

Очень красиво сказано, однако чаще решение принимаются не столь идеалистично. У всех есть некоторый опыт, все имеют некую консервативность и придерживаются некоторого стиля... Я вот, по собственной воле вряд ли буду делать толстую domain model или работать с dataset'ами, хотя опыта в этом у мало для того чтобы так категорично судить.

G>>И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.
VPV>да это правда — хуже не придумаешь... такое решение очень плохо сказывается на производитлеьности, масштабируемости системы... я сомневаюсь что кто-то захочет воплотить такое решение по собственной воле.

Согласен.

O>>> Проблемы (и вопросы) решения N2:
O>>> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O>>> 2. как работать с временем жизни объектов?
O>>> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O>>> 4. будут ли маршалиться NHibernatе'овские прокси?
G>>Это худший вариант развития событий.
G>>1)На любое дергание объекта придется бегать на сервер
G>>2)Все изменения надо передавать клиентам
G>>3)Проблемы с контролем времени жизни
VPV>.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.

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

Здравствуйте, Ocenochka

S>>А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами.
O> А если потребуется, от что? Нельзя будет учесть версию объекта, или транзакционность БД как-то отменится?

Вы меня неправильно поняли — я писал про блокировку намерения — она имеет смысл только для вашего приложения. Но и optimistic concurrency это тоже относится.

S>>Данные у вас лежат в СУБД — любой запрос может помацать их несмотря ни на какие псевдоблокировки.
O> Раскажите, наконец, каким образом? Например, есть объект "клиент" у него есть свойство "счет". Объект имеет версию, лежит в БД. Дав клиента забирает его из БД, изменяют и пытаются положить обратно предварительно проверив версию объекта. Как возможна коллизая, эсли "помацать" — это коллизия ?

Легко, если клиент другой системы не использует оптимистическую блокировку и созраняет изменения после вас. Если не делать проверки силами самой СУБД — через триггеры или хранимые процедуры.

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

O> Решением моей проблемы является архитектура, которую на каждое новое требование заказчика не надо будет сильно переписывать.
как говрится — дьявол кроется в деталях архитектура это карта описывающая способ решения, но сама по себе не является ее решением, имеено чатью архитектурного процесса и является создание и описание решения проблемы... (но это вне темы данного топика)

VPV>>а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

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

собственно кто какие роли в проекте играет не имеет значени — это может сказываться толко на качестве результата, я про аналитика сказал для того, что прежде чем решать проблему вам нужны буду знания о требуемом поведении системы в том или ином случае (ее состоянии)...
пример:
вы клиент 1, я клиент 2. вы бирете Business Entity (BE) и я биру ту же BE. оба делаем изменения, чью версию сохраняем ? при такой постановке вопроса — проблема решения не имеет, но как только мы введем допольнительные правила — например по премени изменений (вы раньше взял я позже), по приоритеру ролей (у вас роль с низким приоритетом и для внесения измений в хранилище ваши данные должны еще пройти утверждение у менеджера), т.д. правила могут быть разные... т.е. нужно уточнить необходимое поведение системы.

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

O> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.

первая часть — контроллер принимает решение о необходимости извещения представлений...
вторая часть — сто является тригером для принятия этого решения конт роллером, думаю, вам видней — это может быть save, изменение страницы, автосейв и т.д. вам видней.

нажатие на кнопки сохранить на клиенте 1 не может быть уведомлением сервера для других клиентов, — это может быть триггером контроллера для запуска процесса сохраниение, в рамках которого можгут быть уведомлены об изменениях модели другие клиенты, а могут быть и не уведомлены

O>>>>>>>Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.

проблемы могут быть разные — в если хотите иметь их полный список — опишите UC сохранениея BE в формальной форме — и для каждого пункта в основном потоке сделайте алтернативу... чем точнее будет ваш основной поток, тем точнее вы сможите составить список возможных альтернатив, тем полнее будет картина возможных проблем

G>>>>Создавать сферическую архитектуру в вакууме не получится.
да это правильно — хотя бы потому что архитектура это решение проблемы — нет проблемы нет решения

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

O> Мне вот сейчас интересно стало как общий случай трехзвенки реализуется. Логика работы с данными выносится на сервер, а на каждом клиенте дополнительно своя небольшая логика? Т.е. алгоритм примерно такой? :
O> 1. Клиент запрашивает у сервера нужные объекты через сервис.
O> 2. Сервер получает объекты из БД и отдает на клиента, сериализуя.
O> 3. Клиент работает с объектами через свою логику, параллельно обращаясь на сервер по необходимости (что бы залочить например объект)
O> 4. Клиент возвращает объекты серверу с просьбой сохранить состояние, в случае проблем дополнительная логика на клиенте разруливает проблемы.

Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.

O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?

Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.

O> Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
O> Что в 2-х звенке, что в 3-х — неужели только логи?

А чем не устраивают логи? Возьмите log4net, отлично фильтруются снаружи, есть средства онлайн мониторинга, можно ошибки кидать по почте.

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

M>Да. Там 9 страниц, со второй начинается интересное: "The Cost of GUIDs as Primary Keys", http://www.informit.com/articles/article.aspx?p=25862

Ну да, вобщем-то я сам те же доводы приводил в форуме БД, даже тесты делал, а мне твердили GUID'ы наше все. Не пойму, что мешает команде MSSQL сделать нормальный сиквенс, который подерживают практически все промышленные субд. Впрочем оффтопик.

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

Z>Ну да, вобщем-то я сам те же доводы приводил в форуме БД, даже тесты делал, а мне твердили GUID'ы наше все. Не пойму, что мешает команде MSSQL сделать нормальный сиквенс, который подерживают практически все промышленные субд. Впрочем оффтопик.

Плохому танцору (т.е. MsSQL) .. )) Нормальный сиквенс можно симулировать триггером и таблицей, может, поэтому и не хотят -- и так прокатывает.
Насчет "guid'ы наше все" -- для таких оригиналов в nhibernate есть guid.comb, как я уже сказал

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

Z>Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.
Именно поэтому есть желание отказаться от SOAP-service и перейти на REST-like DAO -- не нужно будет по каждому чиху менять WSDL. (О своем: вообще считаю, что в таком случае SOAP WebService был выбран неудачно)

Z>Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.
Если сервер исключительно DAO-контейнер, то чисто толстый клиент в 3хзвенке иметь смысла не вижу, тем более при наличии Nhibernate ; лучше тогда 2хзвенка + shared cache. Тут, конечно, свои нюансы, например, интеграция с другими системами, требующая сервера, или хитрая репликация средствами серверной логики.

Z>А чем не устраивают логи? Возьмите log4net, отлично фильтруются снаружи, есть средства онлайн мониторинга, можно ошибки кидать по почте.
Мне кажется, он что-то другое имеет в виду )

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

O> Да, я имел ввиду состояния, нарущающие бизнес-логику, например, в БД у клиента хранятся записи, что он был в одно и то же время в разных местах или что-нибудь такое, причем повторить такое не получается. Обычно можно строить предположения и проверять их по очереди, зная архитектуру, но это часто долго, а иногда и придумать что-то сложно. Я представляю, что только по логам, в которые писать все опериции над объектами и соответственно идентификаторы объектов. Но лог писать на каждое действие — это несколько бъет по производительности, а если клиент удаленный, то все еще хуже т.к. придется просить клиента, чтобы он логи прислал, или делать механизм выгрузки логов... в общем не ясно какие механизмы применять в случае обнаружения ошибочных данных в БД.

У нас есть логи правок, хранящиеся в БД -- например, по сохранению объектов в таблицу логов кладется предыдущее состояние объекта, упакованное в xml и пожатое для компактности. Потом с него можно восстановить объект на нужную версию. Периодически лог чистится согласно админ. политикам. Для некоторых сложных объектов ведется история правок как понятия предметной области.
Счас это все делается триггерами, но есть желание в новой системе перевести это на message-based system -- MSMQ или аналог (ApacheMQ, RabbitMQ), чтобы БД была меньше загружена и не сказывалось на производительности в целом.

Есть также логгирование исходящих запросов на интеграцию со сторонними системами, логгирование входящих/исходящих репликаций. Есть еще автоматизированный валидатор, но его возможности в настоящий момент ограничены проверкой метаданных.

Логгирование при помощи log4net -- есть, но так, для ясности, оно в работе не используется, только при отладке багов.

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

M>Именно поэтому есть желание отказаться от SOAP-service и перейти на REST-like DAO -- не нужно будет по каждому чиху менять WSDL. (О своем: вообще считаю, что в таком случае SOAP WebService был выбран неудачно)

Согласен, но у нас вообще remoting+binary serialization по некоторым причинам.

Z>>Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.
M>Если сервер исключительно DAO-контейнер, то чисто толстый клиент в 3хзвенке иметь смысла не вижу, тем более при наличии Nhibernate ; лучше тогда 2хзвенка + shared cache. Тут, конечно, свои нюансы, например, интеграция с другими системами, требующая сервера, или хитрая репликация средствами серверной логики.

+1

M>Мне кажется, он что-то другое имеет в виду )

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

S>>>А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами.
O>> А если потребуется, от что? Нельзя будет учесть версию объекта, или транзакционность БД как-то отменится?
S>Вы меня неправильно поняли — я писал про блокировку намерения — она имеет смысл только для вашего приложения. Но и optimistic concurrency это тоже относится.

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

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

M>У нас есть логи правок, хранящиеся в БД -- например, по сохранению объектов в таблицу логов кладется предыдущее состояние объекта, упакованное в xml и пожатое для компактности. Потом с него можно восстановить объект на нужную версию. Периодически лог чистится согласно админ. политикам. Для некоторых сложных объектов ведется история правок как понятия предметной области.
M>Счас это все делается триггерами, но есть желание в новой системе перевести это на message-based system -- MSMQ или аналог (ApacheMQ, RabbitMQ), чтобы БД была меньше загружена и не сказывалось на производительности в целом.
M>Есть также логгирование исходящих запросов на интеграцию со сторонними системами, логгирование входящих/исходящих репликаций. Есть еще автоматизированный валидатор, но его возможности в настоящий момент ограничены проверкой метаданных.
M>Логгирование при помощи log4net -- есть, но так, для ясности, оно в работе не используется, только при отладке багов.


Все понял, спасибо.

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

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

G>>>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
O>>> Как не надо? А как об изменении смогут узнать другие клиенты?
G>>Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать?

O> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.
Это я понял, я не понял зачем передавать что-то на сервер до нажатия save без обратной связи.

G>>>>Создавать сферическую архитектуру в вакууме не получится.
O>>> Однако, глядя на ваши ответы, я считаю, что у вас это вполне получается Без обид.
O>>>Просто я не вижу у вас понимания решения N1.
G>>Это у тебя нету понимания решения N1, я такие решения в разных видах уже делал.
O> С тонкой domain model делал?
Я только с тонкой сейчас и работаю.

O>>>То, что вы пробовали городить dataset'ы — это я уже выяснил
G>>Мимо. Как раз решения с dataset я предпочитаю не городить, я один раз начал такое делать и быстро отказался.
O> А как делал?
Что именно?

O>>>>>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>>>>>Оба неадекваты на 99%
O>>>>> Предлагайте!
G>>>>Сделать кнопку Save, по которой сохранять изменения.
G>>>>Далее 3 варианта:
G>>>>1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)
O>>> В задаче сказано, что БД — одна.
G>>И что? SQL CE — несколько dll и больше ничего не надо

O> Я знаю, что такое SQL CE и работал с ней, однако, синхронизация должна быть чаще чем раз в минуту. Городить для этого репликацию из локальных БД... Синхронизацию руками проводить? Чем локальный кэш NHibernate хуже, чем локальная БД?
Есть sync framework, который все сам делает. А лучше кеша потому что всетаки РСУБД, а не коллекция объектов в памяти.
Но если актуальность информации важна, то лучше локальным кешированием оперативных данных не заниматься. Только справочники.

G>>>>2)Написать кучу сервисов и DTO
O>>> Это зачем и к чему?
G>>Ко всему. Если клиент не толстый, то лучше увеличить гранулярность обращения к серверу. Для этого потребуется метод сервиса и вероятнее всего DTO.
O> Клиент толстый.
Если толстый — тогда вариант ниже.

G>>>>3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services
O>>> Каким образом?
G>>Создть модель в EF дизайнере, создать сервис ADO.NET, сделать клиент.
O> Не пробовал EF, слышал негативные отзывы, как работает — не представляю. В чем преимущества?
Ты EF при таком подходе даже не увидишь
Посмотри примеры с ADO.NET Data Services — удивишься. Через полгода как раз доделают сихнхронизацию через эти сервисы и допилят нужный функционал (сейчас доступен в CTP).


O>>> Есть четкая задача, которую я обозначил дважды, повторю еще раз: есть два клиента, работающих с общей БД. Как реализовать их работу при отсутствии коллизий?
G>>Наверное при наличии коллизий. Варианта как всегда два:
G>>1)пессимистичная блокировка — когда данные могут меняться только одним клиентом в один момент времени.
G>>2)оптимистичная блокировка, когда оба редактируют данные, если при попытке сорхнанить версии не сопадают — исправить конфликт и попытаться еще раз.
G>>Оптимистичная блокировка на самом деле блокировкой не является, несмотря на назание, и в некоторых случаях не работает.

O> Почему не работает? У же который раз пишут, что может не работать, однако я не представляю как это возможно в случае наличия версии в каждой сущности и транзакционной БД.
Сценарий.
Для корректного обновления X надо прочитать из Y, выполнить запрос на внешний сервис с данными из Y, записать результат в X.
Один клиент читает Y, начинает выполнять запрос, в этот момент другой клиент меняет Y. Так как первый клиент Y не менял, то конфликт версий при сохранении даже не будет проверяться, тем не менее данные будут несогласованы.

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

Z>Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.

Спасибо, опять все понятно

O>> Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
O>> Что в 2-х звенке, что в 3-х — неужели только логи?
Z>А чем не устраивают логи? Возьмите log4net, отлично фильтруются снаружи, есть средства онлайн мониторинга, можно ошибки кидать по почте.

Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.

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

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

Z>>>Примеры неDDDшных конструкций в студию.
G>>В основном дополнительные классы для работы с произвольными выборками. Не помню уже все давно это было и на делфи.
Z>Почему ты решил, что эти кклассы "неDDDшные"? Рич модель не обязана состоять только из персистных классов. Она отличается от тонкой только тем, что допускает логику в персистных, но нигде не говорится об обязательном отсутствии BL в других классах.
И что? Получим размазываение логики? нет уж, спасибо.

G>>Еще раз модель — часть программы. Рассматривать модель отдельно от программы смылса нету.
G>>Не бывает модель ценной сама по себе.

Z>>>Это не философия, если ты не выделяешь подобного ядра — тебе надо быть уверенным во всей программе.
G>>А если бы выделял ядро, то не надо было бы быть уверенным?

Z>Это уже пошла философия. Есть критические ошибки в БЛ, которые стоят очень дорого. Есть некое ядро, при корректности которого нарушить БЛ сложно/невозможно. Чем компактнее это ядро, тем легче его поддерживать. Я убежден, что рич модель позволяет сделать такое ядро более компактным и проще поддерживаемым. Правда требует большей квалификации при его дизайне.
Уж точно философия. Я всетаки тесты предпочитаю чтобы быть уверенным.

Z>Пример из практики, при переводе на клиент-сервер одной из систем сделали из рич модели тощую, руководствуясь примерно теми же мотивами, что и ты декларируешь. Ядро логики мне не удалось изолировать так же хорошо как и в жирной, хотя я проектировал ее на три года позже чем жирную (смею надеяться, что за три года в голове прибавилось ). Реюз кода уменьшился и, как я ни старался, сейчас требуется намного больше знаний о системе для написания новой логики. Сейчас я уже не так уверен, что решение проблем рич модели было бы дороже. И уж точно не сомневаюсь в праве рич моделей на жизнь.
Я даже не смоневаюсь что переделка rich в anemic даст такой эффект.
Это примерно как попробовать переделать OO-программу в функциональную.

G>>Я вообще-то тесты пишу.
Z>Дада, и в твоих программах больше нет ни одной ошибки. Рич модель несоместима с тестами чтоли?
Совместима, только все разговоры о "ядре" больше ни к чему.

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

G>>>>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
O>>>> Как не надо? А как об изменении смогут узнать другие клиенты?
G>>>Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать?
O>> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.
G>Это я понял, я не понял зачем передавать что-то на сервер до нажатия save без обратной связи.

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

O>> Почему не работает? У же который раз пишут, что может не работать, однако я не представляю как это возможно в случае наличия версии в каждой сущности и транзакционной БД.
G>Сценарий.
G>Для корректного обновления X надо прочитать из Y, выполнить запрос на внешний сервис с данными из Y, записать результат в X.
G>Один клиент читает Y, начинает выполнять запрос, в этот момент другой клиент меняет Y. Так как первый клиент Y не менял, то конфликт версий при сохранении даже не будет проверяться, тем не менее данные будут несогласованы.

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

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

VPV>.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.
Ох сколько подводных камней этот путь таит, лучше даже не считать.

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

O> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.

Да нет, мы в фаре смотрим, анхендлед экзкпшены сервера по почте шлются.

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

G>Я даже не смоневаюсь что переделка rich в anemic даст такой эффект.
G>Это примерно как попробовать переделать OO-программу в функциональную.

На этой оптимистичной ноте предлагаю закрыть дискуссию, полезных знаний мне она точно не приносит, тебе как я вижу тоже. Предлагаю считать, что я плохо справляюсь с недостатками анемик модели, а ты рич.

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

O> Видимо, придется лочить дерево зависимых объектов, как уже упомянал meowth.
Это уже будет пессимистичная блокировка.

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

O>> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.
Z>Да нет, мы в фаре смотрим, анхендлед экзкпшены сервера по почте шлются.

Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе.

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

O> Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе.

SmtpAppender
log4net Config Examples

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

O>> Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе.
Z>SmtpAppender
Z>log4net Config Examples

Спасибо, запомню на будующее. А не подскажете, что произойдет, если в момент исключения почтовый сервер или транспорт будут не доступны? Отправится ли исключение позже или потеряется?

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

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

O> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.

Можно смотреть логи в Apache Chainsaw. Для более детального просмотра, конечно, стоит написать свой тул.

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

G>Есть sync framework, который все сам делает. А лучше кеша потому что всетаки РСУБД, а не коллекция объектов в памяти.
G>Но если актуальность информации важна, то лучше локальным кешированием оперативных данных не заниматься. Только справочники.

По-моему, вы напрасно впариваете тут Синк Фреймворк. Не тот сценарий, не та задача -- имхо не надо клиент-сервер превращать в распределенную БД. То что Синк умеет делать репликации, это очень хорошо, но здесь это не надо, судя по постановке задачи.

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

O>> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.
M>Можно смотреть логи в Apache Chainsaw. Для более детального просмотра, конечно, стоит написать свой тул.

Ясно, спасибо за общение, очень понравилось!

Здравствуйте, Ocenochka, Вы писали:
O> Ясно, спасибо за общение, очень понравилось!

Не за что. Спрашивайте, может, и помогу чем, если знаю и буду тут.
Я бы вам еще порекомендовал на эту тему с Mike Chaliy пообщатьсо. Правда, имхо они куда-то далеко утопали, Fluent NHibernate + не знаю, юзают ли Spring.NET; но он конкретный практик, и много интересного рассказывает из своего опыта.

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

M>Не за что. Спрашивайте, может, и помогу чем, если знаю и буду тут.
M>Я бы вам еще порекомендовал на эту тему с Mike Chaliy пообщатьсо. Правда, имхо они куда-то далеко утопали, Fluent NHibernate + не знаю, юзают ли Spring.NET; но он конкретный практик, и много интересного рассказывает из своего опыта.

Еще раз спасибо!