Сообщение Re: Про обновление GUI до получения ответа сервера от 08.12.2024 13:29
Изменено 08.12.2024 13:33 bnk
Re: Про обновление GUI до получения ответа сервера
Здравствуйте, Shmj, Вы писали:
S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?
AFAIK создается "центральное" состояние приложения (ака "база данных" в GUI, в простейшем случае просто объект состояния приложения) с транзакциями, которая синхронизуется с "серверной версией".
Проблема синхронизации баз достаточно хорошо изучена, есть много библиотек и сервисов ее обеспечивающих.
Версионирование как наиболее простое, что можно сделать.
Т.е. по сути чтобы такая система "пост-обновлений" нормально работала, нужен работающий механизм транзакций и undo/redo, который будет для нее базой.
Изменения в GUI накатываются через CQRS, модель никогда не модифицируется напрямую.
Из готовых сервисов google firebase например или microsoft fluid.
S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?
AFAIK создается "центральное" состояние приложения (ака "база данных" в GUI, в простейшем случае просто объект состояния приложения) с транзакциями, которая синхронизуется с "серверной версией".
Проблема синхронизации баз достаточно хорошо изучена, есть много библиотек и сервисов ее обеспечивающих.
Версионирование как наиболее простое, что можно сделать.
Т.е. по сути чтобы такая система "пост-обновлений" нормально работала, нужен работающий механизм транзакций и undo/redo, который будет для нее базой.
Изменения в GUI накатываются через CQRS, модель никогда не модифицируется напрямую.
Из готовых сервисов google firebase например или microsoft fluid.
Re: Про обновление GUI до получения ответа сервера
Здравствуйте, Shmj, Вы писали:
S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?
AFAIK создается "центральное" состояние приложения (ака "база данных" в GUI, в простейшем случае просто объект состояния приложения) с транзакциями, которая синхронизуется с "серверной версией".
Проблема синхронизации баз достаточно хорошо изучена, есть много библиотек и сервисов ее обеспечивающих.
Версионирование как наиболее простое, что можно сделать.
Т.е. по сути чтобы такая система из "варианта 2" нормально работала, нужен работающий механизм транзакций и undo/redo, который будет для нее базой.
Изменения в GUI накатываются через CQRS, модель никогда не модифицируется напрямую.
Из готовых сервисов google firebase например или microsoft fluid.
S>И такой вопрос. Если выбрали вариант 2, то может возникнуть такая проблема. Допустим, установили цвет объекта и размер объекта. Сразу изменили в GUI и отправили 2 запроса. При этом первый запрос вернет что изменен цвет, но размер еще не изменен (т.е. второй запрос еще не исполнен — а размер указали во втором запросе, при этом в GUI — уже установили все). Как быть — как лучше такие ситуации обрабатывать?
AFAIK создается "центральное" состояние приложения (ака "база данных" в GUI, в простейшем случае просто объект состояния приложения) с транзакциями, которая синхронизуется с "серверной версией".
Проблема синхронизации баз достаточно хорошо изучена, есть много библиотек и сервисов ее обеспечивающих.
Версионирование как наиболее простое, что можно сделать.
Т.е. по сути чтобы такая система из "варианта 2" нормально работала, нужен работающий механизм транзакций и undo/redo, который будет для нее базой.
Изменения в GUI накатываются через CQRS, модель никогда не модифицируется напрямую.
Из готовых сервисов google firebase например или microsoft fluid.