Здравствуйте, Sinix, Вы писали:
O>>Даже не знаю как рассказать... Довольно специфично, думаю никто тут не сталкивался с этой предметной областью. Давайте считать, что это продажа билетов на самолеты с дополнительными услугами. S>Хотите расскажу страшную тайну? S>РЖД довольно долго резервировало за отдельными регионами диапазоны билетов и переодически делало синхронизацию. Учитесь
А как насчет поддержания в актуальном состоянии базы внутри региона? Если разные кассы параллельно продают билеты из одного зарезервированного диапазона?
S>А для вашего сценария давно придуманы блокировки намерения: вы говорите серверу "я зарезервировал этот ресурс тогда-то" и периодически обновляете время "захвата". Захват кем-то другим возможен по истечении интервала, который заведомо больше интервала обновления. Для красоты можно прикрутить сборку мусора по расписанию.
Не совсем представляю как применить это в моем случае. У меня резервирование равносильно продаже, потому как регион только один.
S>Аппсервер вам ничем не поможет в плане когерентности данных. Наоборот отхватите проблем. // Не-не, никакого холивара. Я говорю только о concurrency management силами аппсервера.
Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
Вообще, я сам пока не вижу причин, почему на каждом клиенте не иметь свой кэш, раз уж все равно данные оторваны от БД. А кэш обновлять по мере необходимости. Или вообще не иметь кэша — все равно все операции редактирования (insert/update/delete) нужно будет отправлять в БД по требованию.
O>>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save". S>Некорректно выразился. Важен не размер а продолжительность.
Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[7]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O>>>Потенциально, размер "unit of work" не большой и зависит, как я понимаю, от количества сделанных пользователем изменений до нажатия кнопки "Save". S>>Некорректно выразился. Важен не размер а продолжительность.
O> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
Речь не о скорости обновления, а о том что пользователь мог начать редактировать и уехать на обед не закончив.
Re[8]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, samius, Вы писали:
O>> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД. S>Речь не о скорости обновления, а о том что пользователь мог начать редактировать и уехать на обед не закончив.
Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка. В оптимистической блокировке можно таймаут сделать и опять-таки обламать ушедшего на обед. Другими словами, в моем случае такой клиент не прав. Общие данные не будут большими документами, а только бизнес-сущностями с несколькими, ну может десятками, свойств.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[7]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> А как насчет поддержания в актуальном состоянии базы внутри региона? Если разные кассы параллельно продают билеты из одного зарезервированного диапазона?
Гммм... вообще-то это был стёб на тему как делать не надо — разделение на диапазоны работало крайне отвратительно (никакого отношения к РЖД не имею, источник тоже давно оттуда ушёл — в 2004-м вроде).
O> Не совсем представляю как применить это в моем случае. У меня резервирование равносильно продаже, потому как регион только один.
У вас дело в том чтобы не продать один и тот же ресурс несколько раз, так?
Так вот. Когда вы начинаете обслуживать реального клиента (человека), вы ставите блокировку намерения ("щас продам!") и периодически её изменяете.
Если вам не удалось поставить блокировку — вы не можете ничего продать и всё
Учтите, что тут не совсем блокировка с точки зрения СУБД, это тупо флажок "зарезервировано для продажи".
O> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша.
Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?
Аппсервер даёт выигрыш в масштабировании за счёт того что все сессии не хранят состояние. Как только вы начинаете согласовывать состояния разных клиентов, вы получаете обратно проблемы с блокировками и прощай масштабируемость. Быстродействие одного клиента от аппсервера не выиграет никак.
S>>Некорректно выразился. Важен не размер а продолжительность. O> Подолжительность то же не большая — обновить массив из 10-100 (ну максимум 1000) объектов в БД.
Ухх... продолжительность не save а всего сеанса обслуживания — вам же придётся держать блокировку намерения всё время чтобы никто не отобрал у вас ресурс.
O> Вообще, я сам пока не вижу причин, почему на каждом клиенте не иметь свой кэш, раз уж все равно данные оторваны от БД. А кэш обновлять по мере необходимости. Или вообще не иметь кэша — все равно все операции редактирования (insert/update/delete) нужно будет отправлять в БД по требованию.
Всё что я писал не отменяет кэша — это просто способ захвата свободных ресурсов без удержания сессии.
Приведите в общем последовательность действий когда вы получите конфликт при сохранении. И посмотрите что будет если резервировать ресурсы по мере необходимости.
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка.
При пессимистической блокировке другие клиенты не смогут отредактировать документ, пока уехавший на обед не сделает Save или Cancel. А тот сценарий который ты описал — оптимистический.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, gandjustas, Вы писали:
G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
Тем, что требует DTO для передачи данных?
Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO. То, что называется тонком моделю по сути моделью не является, это DTO, моделью для которых служит БД. Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели). В жирной модели между БД и приложением появляется еще один слой — модель предметной области, которая реально является моделью, которую разработать не проще чем модель физического процесса и оправдывает она себя лишь на каком-то пороге сложности предметной области.
У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель. Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой.
Вобщем Фаулер и Эванс не пропагандируют overarchitect, они лишь рассказыват как подняться на еще одну ступеньку в борьбе со сложностью продукта. Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[8]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, 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>Приведите в общем последовательность действий когда вы получите конфликт при сохранении. И посмотрите что будет если резервировать ресурсы по мере необходимости.
Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных?
Т.е. придется обновлять данные не только после процедуры оформления, но и перед, чтобы убедиться, что ресурс не занят и занять его?
Да, в случае длительных операций с большим числом ввода данных от пользователя это имеет смысл, согласен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, IB, Вы писали:
O>> Придет с обеда и не сможет сделать "Save", потому что другие клиенты уже отредактируют данные и их версия изменится. В терминологии это звучит как песимистическая блокировка. IB>При пессимистической блокировке другие клиенты не смогут отредактировать документ, пока уехавший на обед не сделает Save или Cancel. А тот сценарий который ты описал — оптимистический.
Ясно, спасибо, различие и плюсы обоих случаев уловил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[3]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ziaw, Вы писали:
G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос. Z>Тем, что требует DTO для передачи данных?
Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
Z>Я на досуге подумал и пришел к такому выводу. Различие между тонкой и жирной моделью лишь в способе получения DTO. То, что называется тонком моделю по сути моделью не является, это DTO, моделью для которых служит БД. Поэтому зачастую с тонкой моделью легко уживается логика в БД (логика в модели). В жирной модели между БД и приложением появляется еще один слой — модель предметной области, которая реально является моделью, которую разработать не проще чем модель физического процесса и оправдывает она себя лишь на каком-то пороге сложности предметной области. Z>У нее полно минусов, она очень неоптимально использует СУБД, нам требуется трекать изменения сделанные клиентом, чтобы проапдейтить эту модель.
Тут все об одном и том же — о производительности, с чем я согласен, однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру. Поэтому я и написал, что в моем понимании адекватность реализации оценивается не скоростью работы, а в первую очередь временем написания/отладки/поддержки.
Z>Но, грамотно построенная, она не позволяет нарушить ни одного бизнес правила и дает максимально полный интерфейс для работы над собой. Z>Вобщем Фаулер и Эванс не пропагандируют overarchitect, они лишь рассказыват как подняться на еще одну ступеньку в борьбе со сложностью продукта. Любой такой шаг не бесплатен и любой оправдан лишь в тех случаях, когда без него гораздо хуже.
Согласен, однако рассуждения на эту тему плохо вписываются в топик
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> В начале подумал, что стеб, а потом решил, что "не мог же ржд работать не правильно"
А почему? Наоборот очень полезно искать косяки у авторитетов — у них как правило и косяки покруче обычных.
O> В моем случае, не критично, если кассир скажет, что билет есть, начнет процедуру введения данных пользователя а в итоге (при нажатии на кнопку "Save") обломится.
Неее, это со стороны как жуткий отстой смотрится: "ой, у нас система не работает" против "вы знаете, все билеты разобраны"
Усилия здесь окупятся — там работы на 5 минут — добавить метод TryReserveResource и обновлять блокировку по памяти.
O>>> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша. S>>Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени?
O> Да
А зачем им — пользователь должен выбирать? Тогда в 2 этапа — при начале обслуживания забираете свободные ресурсы, а потом перебором пытаетесь лочить
O> Под масштабированием подразумевается увеличение числа клиентов?
Да
O> Если правильно понял, то подразумевается что-то вроде продолжительности оформления продажи? Нет, не большая продолжительность.
Ага. Тогда всё вообще классно — достаточно в принципе загрузки данных в начале работы + проверки при сохранении.
O> Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных?
Тут не совсем пессимистическая блокировка — последняя подразумевает удержание сессии и полную невозможность поломать состояние. А вариант с "зарезервировано" дешевле в плане масштабируемости, но уязвимей к некорретному изменению данных. Но да, нечто похожее.
Re[4]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
G>>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос. Z>>Тем, что требует DTO для передачи данных?
O> Думаю в большинстве случаев можно передавать объекты domain model. Логика не должна, на мой взгляд, в них содержаться.
Мы до сих пор говорим о жирной модели? Этот термин был придуман IB и означал модель, классы которой содержат логику, в отличии от тощей, в которой объекты служат лишь хранилищем данных.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinix, Вы писали:
O>> В начале подумал, что стеб, а потом решил, что "не мог же ржд работать не правильно" S>А почему? Наоборот очень полезно искать косяки у авторитетов — у них как правило и косяки покруче обычных.
Мне поиска косяков у себя хватает Хотя иногда все же пускаюсь в рассуждения относительно того как сделано у "авторитетов", но скорее для развлечения и поиска дыр, чем действительно с желанием досконально рзобраться ибо в абсолютном большинстве случаем до правды докопаться не удается.
O>> В моем случае, не критично, если кассир скажет, что билет есть, начнет процедуру введения данных пользователя а в итоге (при нажатии на кнопку "Save") обломится.
S>Неее, это со стороны как жуткий отстой смотрится: "ой, у нас система не работает" против "вы знаете, все билеты разобраны"
Скорее так: "Ой, а этот билет только что кто-то уже купил, хотите другой?". К тому же это будет происходить крайне редко, скорее всего.
S>Усилия здесь окупятся — там работы на 5 минут — добавить метод TryReserveResource и обновлять блокировку по памяти.
Вообще да, согласен.
O>>>> Аппсервер по-идее должен помочь быстродействию наличием единого и непротиворичивого кэша. S>>>Зачем вам единый кэш сдался и как аппсервер может тут помочь? Вам надо чтобы продавцы видели все свободные ресурсы в каждый момент времени? O>> Да S>А зачем им — пользователь должен выбирать? Тогда в 2 этапа — при начале обслуживания забираете свободные ресурсы, а потом перебором пытаетесь лочить
Ну да, как то так.
O>> Под масштабированием подразумевается увеличение числа клиентов? S>Да
Ясно, согласен.
O>> Если правильно понял, то подразумевается что-то вроде продолжительности оформления продажи? Нет, не большая продолжительность. S>Ага. Тогда всё вообще классно — достаточно в принципе загрузки данных в начале работы + проверки при сохранении. O>> Кажется я понял, вы предлагаете пессимистическую блокировку вместо оптимистической? Т.е. не редактировать данные с последующей попыткой их обновить с неизвестным исходом, а лочить данные на время обновления, чтобы другие считали их занятыми, чтобы таким образом свести к минимуму обломы при обновлении измененных данных? S>Тут не совсем пессимистическая блокировка — последняя подразумевает удержание сессии и полную невозможность поломать состояние. А вариант с "зарезервировано" дешевле в плане масштабируемости, но уязвимей к некорретному изменению данных. Но да, нечто похожее.
А как можно некорректно изменить данные, которые имеют версию? Два лока сделать одновременно ведь не удасться даже теоретически, на сколько я понимаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[5]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, 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.
Разрешить на клиентах иметь оторванные от БД данные, но при возможности
их изменения не давать их изменять другим клиентам. То есть, открывая на
изменение объект "Счет", лочить его на уровне бизнес-логики или БД.
Перед открытием проверять не залочен ли он.
> Мне ближе первый вариант, поэтому хотелось бы обсудить его, хотя второй > вариант то же интересен, если кто-то скажет что успешно его реализовывал > и поделится реализацией некоторых непонятных моментов.
Тут все равно остается вопрос про актуальность данных при критических
операциях. Например, перед формированием, скажем, налоговой накладной
необходимо проверять, не изменились ли атрибуты объекта "Клиент".
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Ocenochka, Вы писали:
O> однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру.
Поубивал бы тех, кто пустил эту фразу в народ
Мало того, что перекладывание своих проблем на кошелек заказчика, так еще святая вера в то, что просто добавление еще одного сервера улучшит производительность. А какие изменения в архитектуру ПО вы собираетесь вносить, чтобы ваше приложение хотя бы не стало медленей работать от добавления еще одного сервера?
Здравствуйте, ilvi, Вы писали:
O>> однако, всем известно, что проще купить лишний сервер, чем поддерживать запутанную архитектуру. I>Поубивал бы тех, кто пустил эту фразу в народ I>Мало того, что перекладывание своих проблем на кошелек заказчика,
А разработчики, типа, бесплатно будут ковыряться в кривой архитектуре? Хорошо, если найдете адекватного и согласного копаться в существующем решении Месяц работы 1 разработчика примерно равен стоимости хорошего сервера, а то и двух.
I>так еще святая вера в то, что просто добавление еще одного сервера улучшит производительность.
При наличии соответствующей архитектуры — улучшит. Именно поэтому хорошая архитектура — "залог здоровья". А в условиях активного развития средств виртуализации и без правельной архитектуры может улучшить, на сколько я понимаю.
I>А какие изменения в архитектуру ПО вы собираетесь вносить, чтобы ваше приложение хотя бы не стало медленей работать от добавления еще одного сервера?
Ну чтобы заработало и при этом медленнее чем было — это надо постараться
СУБД вроде хорошо масштабируются, web и win сервисы то же, конечно правильно написаные. Конечно, может быть централизованная архитектура, которая ни чего не даст при покупке дополнительного сервера, но я это не рассматривал — это крайний случай.
зы Еще одна фраза "выпущенная в народ": девять женщин не родят ребенка за один месяц
Что в тематике форума будет звучать, как "9 месяцев работы одного программиста не равны одному месяцу работы 9 программистов в проекте на 9 чел./мес."
Это к вопросу увеличения производительности при добавлении разработчиков и при добавлении серверов
Здравствуйте, Ромашка, Вы писали:
Р>Вариант 3. Р>Разрешить на клиентах иметь оторванные от БД данные, но при возможности Р>их изменения не давать их изменять другим клиентам. То есть, открывая на Р>изменение объект "Счет", лочить его на уровне бизнес-логики или БД. Р>Перед открытием проверять не залочен ли он.
Спасибо, уже рассмотрели. Это скорее разновидность первого варианта.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[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
Мы уже победили, просто это еще не так заметно...
