Сообщение Re: автообновление таблицы от 25.10.2022 6:33
Изменено 25.10.2022 8:51 RushDevion
Re: автообновление таблицы
vaa>Какой подход лучше использовать, чтобы обновить грид вручную при изменении вне действий пользователя.
А это точно нужно? Данные так часто меняются? Что страшного произойдет, если пользователь какое-то время будет видеть неактуальные данные?
vaa>Данные меняются во многих местах.
vaa>Тупо дергать автоматически каждые X секунд или делать подписку по id к какой-то шине, которая уже будет сама дергать базу?
На клиенте — websocket (если REST/http) или streaming (если GRPC), подписываемся на событие. Событие для простоты одно, e.g. serverStateChanged.
Клиент получает событие и перезагружает всю грилу целиком.
На сервере — какой-то хук в процесс сохранения сущностей для публикации события.
Тут от архитектуры и фреймворков зависит.
Например, в mediator это есть практически из коробки
В ef/ef-core можно вклиниться в SaveChanges и даже достать конкретные сущности/поля через change tracker.
В event sourcing фреймворках обычно тоже есть какой-то extension point для сохранения.
Если ничего такого нет — ну втыкнуть публикацию в репозитории при сохранении/удалении.
А это точно нужно? Данные так часто меняются? Что страшного произойдет, если пользователь какое-то время будет видеть неактуальные данные?
vaa>Данные меняются во многих местах.
vaa>Тупо дергать автоматически каждые X секунд или делать подписку по id к какой-то шине, которая уже будет сама дергать базу?
На клиенте — websocket (если REST/http) или streaming (если GRPC), подписываемся на событие. Событие для простоты одно, e.g. serverStateChanged.
Клиент получает событие и перезагружает всю грилу целиком.
На сервере — какой-то хук в процесс сохранения сущностей для публикации события.
Тут от архитектуры и фреймворков зависит.
Например, в mediator это есть практически из коробки
В ef/ef-core можно вклиниться в SaveChanges и даже достать конкретные сущности/поля через change tracker.
В event sourcing фреймворках обычно тоже есть какой-то extension point для сохранения.
Если ничего такого нет — ну втыкнуть публикацию в репозитории при сохранении/удалении.
Re: автообновление таблицы
vaa>Какой подход лучше использовать, чтобы обновить грид вручную при изменении вне действий пользователя.
А это точно нужно? Данные так часто меняются? Что страшного произойдет, если пользователь какое-то время будет видеть неактуальные данные?
vaa>Данные меняются во многих местах.
vaa>Тупо дергать автоматически каждые X секунд или делать подписку по id к какой-то шине, которая уже будет сама дергать базу?
На клиенте — websocket (если REST/http) или streaming (если GRPC), подписываемся на событие. Событие для простоты одно, e.g. serverStateChanged.
Клиент получает событие и перезагружает всю гриду целиком.
На сервере — какой-то хук в процесс сохранения сущностей для публикации события.
Тут от архитектуры и фреймворков зависит.
Например, в mediator это есть из коробки (INotification)
В ef/ef-core можно вклиниться в SaveChanges и даже достать конкретные сущности/поля через change tracker.
В event sourcing фреймворках обычно тоже есть какой-то extension point для сохранения.
Если ничего такого нет — ну втыкнуть публикацию в репозитории при сохранении/удалении.
А это точно нужно? Данные так часто меняются? Что страшного произойдет, если пользователь какое-то время будет видеть неактуальные данные?
vaa>Данные меняются во многих местах.
vaa>Тупо дергать автоматически каждые X секунд или делать подписку по id к какой-то шине, которая уже будет сама дергать базу?
На клиенте — websocket (если REST/http) или streaming (если GRPC), подписываемся на событие. Событие для простоты одно, e.g. serverStateChanged.
Клиент получает событие и перезагружает всю гриду целиком.
На сервере — какой-то хук в процесс сохранения сущностей для публикации события.
Тут от архитектуры и фреймворков зависит.
Например, в mediator это есть из коробки (INotification)
В ef/ef-core можно вклиниться в SaveChanges и даже достать конкретные сущности/поля через change tracker.
В event sourcing фреймворках обычно тоже есть какой-то extension point для сохранения.
Если ничего такого нет — ну втыкнуть публикацию в репозитории при сохранении/удалении.