Архитектура приложения с несколькими клиентами и одним серве
От: Ocenochka  
Дата: 26.05.09 22:03
Оценка:
Уважаемые представители коллективного разума, помогите пожалуйста разобраться.

Задача:
Есть проект, в который входит несколько клиентских приложений (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>>
Люблю ставить оценки.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.