Блог

Мое текущее понимание Blazor webassembly заключается в том, что пользователь загружает приложение, выполняет один первоначальный вызов в веб-API и извлекает набор данных для отображения. Затем пользователь может взаимодействовать с данными локально и вызывать API только тогда, когда пользователь вставляет, обновляет или удаляет элементы. Дальнейшие вызовы «Get» не требуются после первоначального вызова, поскольку состояние данных загружается локально.

Что, если ожидается, что несколько одновременных пользователей будут взаимодействовать с одним и тем же набором данных? Традиционно в стандартном веб-приложении внешние изменения в наборе данных будут видны довольно быстро при перезагрузке страницы и получении нового набора данных из внутреннего хранилища. В некоторых случаях может быть желательно ввести опрос, если ожидается, что пользователь будет долгое время сидеть на странице без перезагрузки.

Я не уверен, что считается лучшей практикой в мире Blazor для обработки такого типа вариантов использования. Является ли опрос веб-API приемлемым решением? Должен ли я использовать SignalR для уведомления клиентов об изменениях в наборе данных? Какой-либо встроенный механизм, который я упустил из виду?

Я не думаю, что Blazor отличается от других фреймворков в этом отношении. Если вы редактируете объект в браузере, у вас есть два варианта:

1. Позвольте каждому пользователю редактировать и сохранять без какой-либо координации между пользователем. Объект будет оставлен в том состоянии, в котором его сохранил последний пользователь.

2. Реализовать какую-то блокировку объекта. Я не знаю, предоставляет ли .NET Core такие вещи, но управлять ими самостоятельно не должно быть сложно. Таким образом, в этом сценарии, если пользователь извлек объект, ни одному другому пользователю не будет разрешено редактировать его, пока не будет возвращена проверка. Но я сомневаюсь, что такая стратегия будет работать с приложениями общего назначения. Для предприятия это может сработать. Проблема в том, что кто-то закрывает свой браузер перед возвратом объекта. Ни один другой пользователь не сможет получить доступ к объекту, пока вы не введете какой-либо тайм-аут. Обновление: Ядро EF имеет функцию обнаружения параллелизма, и вы можете настроить его для вызова исключения DbUpdateConcurrencyException. Затем вы можете использовать это, чтобы либо перезаписать изменения, внесенные другим пользователем, либо предоставить пользователю возможность перезагружать новые данные и т.д.

Что касается обновления данных, общая практика, похоже, заключается в получении данных при инициализации компонента, внесении изменений и последующем сохранении их обратно. Было бы редко, если бы вы захотели повторно извлекать промежуточные данные, хотя вы могли бы делать это так часто, как пожелаете. Но это также будет обновлять пользовательский интерфейс снова и снова.

После некоторых исследований единственным стандартным, принятым способом сделать это в Blazor Webassembly является использование SignalR.