По сути, нужно разобраться с 3 частями.
Компоненты Razor
Это имя ядра, вне процесса, модели компонентов, которая была создана еще вИюль 2018 года, для первого выпуска Blazor на стороне сервера.
Razor Components является ядром платформы и содержит все следующие элементы.
- Параметры
- Обработка событий
- Привязка данных
- Маршрутизация
- Внедрение зависимостей
- Макеты
- Шаблонирование
- Каскадные значения
Blazor на стороне сервера
Это модель хостинга на стороне сервера, работающая в ASP.NET Core, для компонентов Razor.В этой версии размещается модель Razor Components на сервере.Он использует небольшое время выполнения для отправки событий пользовательского интерфейса из браузера на сервер.После обработки компонентами Razor любые обновления пользовательского интерфейса отправляются обратно с сервера в браузер, и среда выполнения обрабатывает обновление DOM.Все эти сообщения обрабатываются через соединение SignalR.Даже вызовы взаимодействия JS обрабатываются таким образом.
Blazor на стороне клиента
Это модель хостинга на стороне клиента для компонентов Razor.
InВ этой модели все размещено в браузере.Mono, скомпилированный в WebAssembly, - это среда выполнения .NET.Помимо этого, находятся компоненты Razor, а затем, наконец, приложение.
Самое замечательное в этой архитектуре заключается в том, что любая функция, добавляемая в компоненты Razor, теоретически должна быть доступна для обеих моделей хостинга.Хотя на самом деле это не всегда так.
Что лучше?
Это очень сильно зависит от того, что вы хотите сделать.
КлиентСамым большим недостатком со стороны Blazors является размер загружаемого файла.Это само по себе может исключить это для многих разработчиков.Загрузки легко делятся на несколько мегабайт, которые, если кто-то пытается просмотреть ваше приложение на мобильном телефоне при медленном соединении, не будут иметь большого опыта.Однако стоит отметить, что после первой загрузки большая часть контента кэшируется, поэтому последующие загрузки могут составлять несколько 100 КБ.
Опыт отладки Blazors на стороне клиента и сейчас очень примитивен.Это означает, что иногда работа над ним как над разработчиком может быть сложной.
У серверной версии Blazor гораздо более приятный опыт разработчика в плане отладки.Приложение гораздо быстрее загружается и имеет размер всего несколько сотен килобайт, прежде чем произойдет кэширование.
Недостатком является потенциальная масштабируемость.Но это будет очень сильно зависеть от количества одновременных пользователей, которых вы ожидаете.Поскольку эта модель использует SignalR, ваше приложение будет иметь верхний предел одновременных подключений.Но вы можете управлять этим, подключившись к Azure SignalR, чтобы обеспечить гораздо большее количество подключений к вашему приложению.
В конечном счете, обеим моделям размещения компонентов Razor предстоит пройти долгий путь.Истории аутентификации для обоих находятся в очень ранние дни, хотя Blazor на стороне клиента, возможно, находится в лучшем месте.Механизм маршрутизации все еще ограничен, формы и валидация только что выпустили его первый выпуск, и еще есть над чем поработать.
Еще одна вещь, которую нужно иметь в виду, это то, что можно довольно легко переключаться между моделями.Поэтому какое бы решение вы ни приняли, вы не привязаны к нему.В какой-то момент даже появится способ сделать это встроенным в фреймворк, поэтому ничто из того, что вы сейчас делаете, не будет потрачено впустую.
Любые вопросы, пожалуйста, задавайте.Но я надеюсь, что это поможет.