Уважаемые представители коллективного разума, помогите пожалуйста разобраться.
Задача:
Есть проект, в который входит несколько клиентских приложений (WinForms) для работы с одними и теми же данными — общая БД.
Сейчас принято решение иметь так же одно серверное приложение содержащее либо только слой доступа к данным, либо еще всю или часть бизнес-логики. В сервере в качестве DAL будет использоваться NHibernate с включенным кэшем.
(Решение о централизованном сервере может быть изменено в случае наличия удовлетворительных аргументов.) Общая проблема:
Наличие коллизий при работе разных клиентов с одними и теми же данными. Т.е., например, оба клиента получили объект, изменили его и отправили обновлять на сервер — в результате произойдет только одно изменение.
Решение N1:
В БД на каждую сущность завести поле с версией сущности, что отразить в маппинге NHibernate.
Основная последовательность:
Клиенты запрашивают у сервера объекты, сервер отдает клиентам отцепленные от кэша сессии объекты. Клиенты их модифицируют и передают для обновления серверу. Сервер пытается прицепить отцепленные объекты и проапдейтить их. В случае если версия объекта не изменилась, апдейтит их, иначе — бросает исключение, клиент его ловит и сообщает пользователю об изменении объекта, пользователь обновляет свой объект и снова пытается его модифицировать, это повторяется пока не будет достигнут успех. Проблемы решения N1:
1. Вполне может потребоваться некое DTO (представляющее из себя смесь части данных разных объектов) в узких местах, как это DTO реализовывать и как отслеживать его версии? В принципе это не очень критично, но все же очень интересно.
2. Не понятно как реализовать пользовательский интефейс:
а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.:
— пользователь может забыть это сделать;
— возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
— не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет
очень не рад вспоминать что он делал и переделывать.
б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
3. Не может ли произойти параллельное увеличение версии объекта на 1 без обнаружения коллизии? Т.е. сервер получает два запроса на обновление одного и того же объекта и пытается (параллельно, в разных потоках) увеличить версию объекта с 1.0 до 1.1, при этом увеличение происходит одновременно и безконфликтно, в результате чего опять-таки происходит только одно измение, которое затирает результат другого изменения. Понятно, что на практике это очень маловероятно, но все же. Интересно какие в этом решении еще могут быть проблемы и как с ними бороться. Тестовый прототип уже пишу, но все равно хочу знать мнение практикующей общественности.
Решение N2:
Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать. Проблемы (и вопросы) решения N2:
1. до конца не понятен механизм разруливания коллизий и возможные сложности;
2. как работать с временем жизни объектов?
3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
4. будут ли маршалиться NHibernatе'овские прокси?
Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
зы Спасибо за внимание!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re: Архитектура приложения с несколькими клиентами и одним с
Здравствуйте, Ocenochka, Вы писали:
O> 2. Не понятно как реализовать пользовательский интефейс: O> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.: O> — пользователь может забыть это сделать;
Дык отслеживайте изменения, например если клиент хочет закрыть форму или перейти на другую закладку, то проверяйте, были ли сделаны изменения, и если да — сообщайте об этом пользователю с предложением сохранить/не сохранять/отменить действие.
O> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx
O> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет O> очень не рад вспоминать что он делал и переделывать.
Не нужно все переделывать, нужно оставить введенные изменения пользователя и сообщить ему в чем конкретно ошибка.
O> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе, O> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
Это просто неправильно так делать.
Re: Архитектура приложения с несколькими клиентами и одним с
Ocenochka, вы чего-то не договариваете. Давайте про предметную область,
потому что непонятно вообще с чего городить весь этот огород с
собственным сервером баз данных.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Re: Архитектура приложения с несколькими клиентами и одним с
Здравствуйте, 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%
Re: Архитектура приложения с несколькими клиентами и одним с
Concurrency control — штука довольно сильно зависящая от предметной области. Мне вот как-то везёт на задачки, когда либо ответственность за изменение данных расписана по людям (и пересечений нет), либо подходит last wins.
Лично я за явный save + возможные проверки перед сохранением. Из опыта людям реально привычно работать в режиме "набросал-поправил-сохранил".
Задача получения изменений в принципе решается легко для внесённых/изменённых строк. С удалёнными строками либо передача всех локальных id на сервер, либо хранение id удалённых строк в вспомогательных табличках на сервере.
На второй вариант забейте сразу.
Re: Архитектура приложения с несколькими клиентами и одним с
Здравствуйте, Ocenochka, Вы писали:
O>Уважаемые представители коллективного разума, помогите пожалуйста разобраться.
O> Решение N2: O> Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть. O> Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать. O> Проблемы (и вопросы) решения N2: O> 1. до конца не понятен механизм разруливания коллизий и возможные сложности; O> 2. как работать с временем жизни объектов? O> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером? O> 4. будут ли маршалиться NHibernatе'овские прокси?
O> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
O>зы Спасибо за внимание!
День добрый. Не знаю насколько практично маршалить все объекты по ссылке, не разу с таким не сталкивался, но как то настараживает
По существу. Ваши два решения мне напоминают решения с песимистической и оптиместической блокировкой.
В первом случае мы оптимистично надеемся, что никто кроме нас не будет редактировать объект и проверяем это только перед применением изменений. При этом все изменения мы применяем в одной транзакции, чтобы не получилось, что часть изменений прошла, а часть нет. Думаю в NHibernate транзакции есть...
Во втором случае, мы перед тем как приступить к редактированию лочим объект и не отпускаем его до завершения редактирования. В таком случае, мы всегда уверены, что никто не изменил наш объект в то время как мы его редактировали. Возможный выход клиента залочившего объект и не отпустившего блокировку лечится установкой таймаутов.
Минусы первого решения, нужно с минимальными трудозатратами будет показывать пользователю как изменился объект, чтобы он решил перетирать сохраненые другим пользователем данные или нет. Эту проблему вы и сами озвучали.
Минусы второго решения, пользователи не очень любять наблюдать сообщение : "данный объект редактирует другой, пользователь. дождидесь завершения."
... << RSDN@Home 1.2.0 alpha 4 rev. 1218>>
Re[2]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, MozgC, Вы писали:
O>> 2. Не понятно как реализовать пользовательский интефейс: O>> а) либо делать кнопку "Save", которую пользователь должен нажимать для применения изменений, что на мой взгляд не удобно т.к.: O>> — пользователь может забыть это сделать; MC>Дык отслеживайте изменения, например если клиент хочет закрыть форму или перейти на другую закладку, то проверяйте, были ли сделаны изменения, и если да — сообщайте об этом пользователю с предложением сохранить/не сохранять/отменить действие.
Не очень понимаю как отслеживать изменения. Допустим на клиенте грид с коллекцией объектов. При редактировании в отдельную коллекцию складывать отредактированные объекты? А как порядок редактирования учитывать?
O>> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты; MC>Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspx
Прочитал. Понял не много и легче не стало. Врапперы над сущностями и их коллекциями — это круто. Не совсем представляю как это будет в случае с несколькими клиентами. DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
O>> — не ясно как разруливать конфликт при серии изменений в которых только одно изменение было неудачно — пользователь будет O>> очень не рад вспоминать что он делал и переделывать. MC>Не нужно все переделывать, нужно оставить введенные изменения пользователя и сообщить ему в чем конкретно ошибка.
А последовательность изменений не учитывать? Если пятая операция из 10 не прошла, то, на мой взгляд, логично откатить все 10. Соответственно, пользователю прдется переделывать все 10.
O>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе, O>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать. MC>Это просто неправильно так делать.
Не правильно делать категоричные заявления без аргументов Ясно, что производительность и отзывчивость могут пострадать, если клиентов будет много, а сервер далеко, но есть подозрение, что дело не в этом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[2]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ромашка, Вы писали:
Р>Ocenochka, вы чего-то не договариваете.
Конечно, я целое тз на ~100 стр. недоговариваю тз писал не я и я в него его еще толком не углублялся, однако основные моменты с несколькими клиентами уже известны.
Р>Давайте про предметную область, потому что непонятно вообще с чего городить весь этот огород с собственным сервером баз данных.
Предметная область, на мой взгляд, не имеет значения. Могу сказать, что это не чистые финансы, но такие объекты как "Клиент" и "Счет" имеются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[2]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, 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%
Предлагайте!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[2]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Sinix, Вы писали:
S>Ух какая благодарная тема-то
Ох и не говорите Это со стороны может весело, а мне делать надо и сроки есть
S>Concurrency control — штука довольно сильно зависящая от предметной области. Мне вот как-то везёт на задачки, когда либо ответственность за изменение данных расписана по людям (и пересечений нет), либо подходит last wins.
К сожалению, не мой случай, хотя может пересечений между разными клиентами будет не так много...
S>Лично я за явный save + возможные проверки перед сохранением. Из опыта людям реально привычно работать в режиме "набросал-поправил-сохранил". S>Задача получения изменений в принципе решается легко для внесённых/изменённых строк. С удалёнными строками либо передача всех локальных id на сервер, либо хранение id удалённых строк в вспомогательных табличках на сервере.
Тут логика понятно, но как это реализовывать? На клиенте держать список(списки) изменений — это ладно. А на сервер передавать то же этот список? Или на сервере только методы по редактированию, а клиент сам знает логику работы со списком измененных и дергает нужные методы сервера?
Предлагаю сделать шаг назад и убрать все принятые архитектурные решения относительно единого сервера и наличия NHibernate. Задача:
Есть несколько клиентских приложений для работы с общими данными. Нужно исключить коллизии при одновременной работе пользователей. Вариант 1.
Разрешить на клиентах иметь оторванные от БД данные и проверять их актуальность при изменении. Вариант 2.
Пытаться всеми силами держать на клиентах только актуальные данные.
В первом варианте недостатком является "относительно небольшая" возможность введения пользователя в заблуждение и необходимость контролировать версии оторванных от БД объектов при применении изменений.
Во втором случае контроль коллизий остается, а заблуждение пользователя устаняется необходимостью работы с DataSet'ами и написание общирной инфраструктуры для поддержания данных на клиенте в актуальном состоянии.
Мне ближе первый вариант, поэтому хотелось бы обсудить его, хотя второй вариант то же интересен, если кто-то скажет что успешно его реализовывал и поделится реализацией некоторых непонятных моментов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[3]: Архитектура приложения с несколькими клиентами и одни
Ocenochka написав(ла): > Предметная область, на мой взгляд, не имеет значения. Могу сказать, что > это не чистые финансы, но такие объекты как "Клиент" и "Счет" имеются.
И ты ради таких объектов, как "Клиент" и "Счет", собрался городить весь
геморрой с трехзвенкой? Зачем? У тебя шансов нарваться на коллизию ноль
целых ноль десятитысячных.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[3]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> К сожалению, не мой случай, хотя может пересечений между разными клиентами будет не так много...
Гммм... а что у вас за случай-то такой страшный?
[offtop]
Спорно конеш, но пересечение больших unit of work чаще всего говорит о бардаке на предприятии.
[/offtop]
O> Тут логика понятно, но как это реализовывать?
Сервер сам решает, можно ли перезаписывать данные и кидает исключение в случае чего.
Или фильтр UPDATE...WHERE...ver=@oldVersion и проверять @@ROWCOUNT.
Клиент ловит исключение — дальше по обстоятельствам. Скорее всего, диалог пользователю -> частичный Upsert и продолжение/перезапуск транзакции (лично я за перезапуск).
Re[4]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ромашка, Вы писали:
Р>И ты ради таких объектов, как "Клиент" и "Счет", собрался городить весь Р>геморрой с трехзвенкой? Зачем? У тебя шансов нарваться на коллизию ноль Р>целых ноль десятитысячных.
Расскажите это заказчику, к которому будут идти недовольные клиенты
К тому же, вероятность зависит от многих параметров, таких как степень перекрещивания данных
между клиентскими приложениями и частота вносимых изменений.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[4]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, 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>Вобщем я к чему — это сложно написать и с этим будет неприятно работать, какие плюсы это дает, чтобы перевести такие минусы?
Плюс один — наличие актуальных данных на клиентах. Вообще-то, я согласен, но хочется рассмротреть все варианты пока есть возможность.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[5]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka
O>Даже не знаю как рассказать... Довольно специфично, думаю никто тут не сталкивался с этой предметной областью. Давайте считать, что это продажа билетов на самолеты с дополнительными услугами.
Хотите расскажу страшную тайну?
РЖД довольно долго резервировало за отдельными регионами диапазоны билетов и переодически делало синхронизацию. Учитесь
А для вашего сценария давно придуманы блокировки намерения: вы говорите серверу "я зарезервировал этот ресурс тогда-то" и периодически обновляете время "захвата". Захват кем-то другим возможен по истечении интервала, который заведомо больше интервала обновления. Для красоты можно прикрутить сборку мусора по расписанию.
То есть вы говорите "я собираюсь использовать такие-то ресурсы, честное слово", а все остальные клиенты радостно вам верят и ничего не портят
Аппсервер вам ничем не поможет в плане когерентности данных. Наоборот отхватите проблем. // Не-не, никакого холивара. Я говорю только о concurrency management силами аппсервера.
O>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save".
Некорректно выразился. Важен не размер а продолжительность.
