Компоненты Razor против Blazor

#asp.net-core #razor #blazor

#asp.net-ядро #razor #blazor

Вопрос:

Я не понимаю, в чем разница между компонентами Razor и Blazor и что лучше, и в последнем выпуске .NET Core 3.0 Preview 3 они добавлены к компонентам Razor

Улучшения компонентов Razor:

  • Единый шаблон проекта
  • Новое расширение .razor
  • Интеграция маршрутизации конечных точек
  • Предварительная визуализация
  • Компоненты Razor в библиотеках классов Razor
  • Улучшена обработка событий
  • Формы и проверка

Комментарии:

1. Компоненты Razor — это Blazor…

2. Это отличная статья в блоге Скотта Хансельмана: hanselman.com/blog/WhatIsBlazorAndWhatIsRazorComponents.aspx

Ответ №1:

По сути, нужно понять 3 части.

Компоненты Razor

Так называется модель компонентов core, out of process, которая была создана еще в июле 2018 года для первого выпуска серверной части Blazor.

Компоненты Razor являются ядром фреймворка и содержат все следующие элементы.

  • Параметры
  • Обработка событий
  • Привязка данных
  • Маршрутизация
  • Внедрение зависимостей
  • Макеты
  • Создание шаблонов
  • Каскадные значения

Blazor на стороне сервера

Это модель хостинга на стороне сервера, работающая на ASP.NET Ядро для компонентов Razor. В этой версии на сервере размещена модель компонентов Razor. Для отправки событий пользовательского интерфейса из браузера на сервер используется небольшая среда выполнения. После обработки компонентами Razor любые обновления пользовательского интерфейса отправляются обратно с сервера в браузер, а среда выполнения обрабатывает обновление DOM. Вся эта связь обрабатывается через соединение SignalR. Таким образом обрабатываются даже вызовы взаимодействия JS.

Blazor на стороне клиента

Это модель хостинга на стороне клиента для компонентов Razor.

В этой модели все размещено в браузере. Mono, скомпилированный в WebAssembly, является .СЕТЕВАЯ среда выполнения. Поверх этого находятся компоненты Razor, а затем, наконец, приложение.

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

Что может быть лучше?

Это очень сильно зависит от того, что вы хотите сделать.

Самым большим недостатком Blazors на стороне клиента является его размер для загрузки. Одно это может исключить это для многих разработчиков. Загрузка легко осуществляется на несколько МБАЙТ, поэтому, если кто-то пытается просмотреть ваше приложение на мобильном устройстве с медленным соединением, у него не будет отличного опыта. Однако стоит отметить, что после первой загрузки большая часть содержимого кэшируется, поэтому последующие загрузки могут составлять несколько 100 кб.

Процесс отладки Blazors на стороне клиента сейчас также очень примитивен. Это означает, что работа над ним в качестве разработчика иногда может быть сложной.

Серверный Blazor гораздо удобнее для разработчиков с точки зрения отладки. Приложение загружается намного быстрее и имеет размер всего в несколько 100 кб, прежде чем произойдет какое-либо кэширование.

Недостатком является потенциальная масштабируемость. Но это будет во многом зависеть от количества одновременных пользователей, которых вы ожидаете. Поскольку эта модель использует SignalR, ваше приложение будет иметь верхний предел одновременных подключений. Но вы можете управлять этим, подключившись к Azure SignalR, чтобы разрешить гораздо большее количество подключений к вашему приложению.

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

Еще одна вещь, которую следует иметь в виду, это то, что можно довольно легко переключаться между моделями. Поэтому, какое бы решение вы ни приняли, вы не привязаны к нему. В какой-то момент даже будет способ сделать это, встроенный в фреймворк, так что все, что вы делаете сейчас, не будет потрачено впустую.

Пожалуйста, задавайте любые вопросы. Но я надеюсь, что это поможет.

Комментарии:

1. спасибо тебе, Крис, за такую большую систему, как erp, которой ты предпочтешь компоненты Blazor или Razor

2. Вот и ответ. Казалось бы, переключаться между Blazor и RC довольно просто. Если вы посмотрите связанное видео, вы увидите это. Докладчик переключается между ними, потому что его материал начался с Balzor вместо RC.

3. Очень хороший ответ, но не актуальный. Модель хостинга на стороне сервера была переименована из Razor Components в Server-Side Blazor on ASP.NET Предварительный просмотр ядра 3.0 4. Подробности здесь . Пожалуйста, обновите, если это возможно.

4. @Guilherme Я обновил ответ, чтобы отразить изменения из предварительного просмотра 4.

5. Задержка также является большой потенциальной проблемой с серверным Blazor. Каждое взаимодействие должно выполняться с обратной связью с сервером, поэтому даже умеренная задержка может привести к разочаровывающему пользовательскому интерфейсу для таких вещей, как ввод формы и меню.

Ответ №2:

Компоненты Razor — это платформа, с помощью которой вы можете создавать веб-приложения SPA. Оно разделено на два режима выполнения. Когда веб-приложение размещено и выполняется в браузере, оно называется Blazor. Приложения Blazor написаны на C # и скомпилированы в .СЕТЕВЫЕ сборки. Они выполняются в браузере как сборки .NET во время выполнения Mono, которое само компилируется в веб-сборку.

Второй способ выполнения — на стороне сервера. То есть ваше веб-приложение выполняется на сервере, а не в браузере. Обратите внимание, что здесь среда выполнения — это не моноблочная веб-сборка, а Asp.net Время выполнения ядра. Это называется Blazor на стороне сервера, но также используется термин Razor Components, так что сбитые с толку люди оказываются в замешательстве. Причина этого историческая: вначале в браузере был запущен только Blazor. Но затем пришла идея, что веб-приложение может запускаться на сервере, и только различия могут быть отправлены в браузер с помощью SignalR. Запустить веб-приложение на сервере намного проще, чем в браузере, и разработчик может использовать многие элементы, которые он не может использовать в браузере, такие как отладка и т.д. В результате этой возможности Asp.Net переименовал фреймворк Blazor в компоненты Razor, которые вы можете рассматривать как суперструктуру, на которой построен Blazor. Вот откуда путаница. Давайте подчеркнем это разделение следующим образом:

Компоненты Razor -> Blazor (интерфейс; браузер)

Компоненты Razor —> Компоненты Razor (Blazor на стороне сервера)

Я знаю, что это источник путаницы, но это все…

Что касается вопроса, что лучше, я могу только сказать, что это зависит исключительно от ваших требований. Каждый из этих режимов выполнения имеет свои преимущества и недостатки. Приложения Blazor больше подходят для запуска в Интернете в качестве общедоступных веб-сайтов, тогда как серверные приложения Blazor лучше всего использовать в Интрасети в качестве корпоративных веб-сайтов.

Отображаемый вами список связан с Razor Components framework. Некоторые улучшения на данный момент могут быть актуальны только для Blazor, другие — для Blazor на стороне сервера. Есть только один способ узнать, что есть что: изучить компоненты Razor. Для его изучения требуется время, меньше, чем Angular, особенно если вы являетесь .Чистый разработчик, но это все еще то, что требует определенных инвестиций.

Надеюсь, это поможет… Позже я улучшу это, но если у вас есть конкретный вопрос, не стесняйтесь задавать…

Комментарии:

1. спасибо Issac за такую большую систему, как erp, которой вы предпочтете компоненты Blazor или Razor

2. @user3903484, пожалуйста, опубликуйте этот комментарий в качестве нового вопроса, чтобы я мог ответить на него соответствующим образом.

3. первое предложение «Компоненты Razor — это фреймворк, с помощью которого вы можете создавать веб-приложения SPA» неверно. удалите «Компоненты Razor» и замените его на «blazor».

Ответ №3:

Вы имеете полное право быть сбитыми с толку, название сильно изменилось, и когда вы писали первоначальный вопрос, команда Blazor недавно переименовала ‘Server Side Blazor’ в ‘Razor Components’. К счастью, с тех пор от этого отказались, подробнее об этом смотрите на временной шкале ниже.

Всем, кто считает, что соглашения об именовании в приведенных здесь ответах, похоже, не соответствуют тому, что они читают в старых сообщениях в блогах, стоит знать, что значение «Компонентов Razor» неоднократно менялось с течением времени.

Это также может помочь любому, кто, как и я, использует Blazor с самого начала и уверен, что названия изменились!

TL; DR

За период подготовки к выпуску названия сильно изменились. Хвала Microsoft и команде Blazor за попытку придумать четкие названия и готовность изменить их при необходимости. Однако это оставило в наследство смешанные соглашения об именовании в старых статьях, и некоторые ветераны Blazor иногда используют старые соглашения об именовании.

На момент написания статьи в сентябре 2020 года, с Blazor версии 3.2, официальным соглашением об именовании является:

Захватывающая история именования Blazor

Октябрь 2018: «Компоненты Razor» становится новым названием для «серверной части Blazor»

Когда был выпущен Blazor 0.6.0, было решено официально назвать серверную часть Blazor «Компонентами Razor».

Дэн Рот обсуждает это в своем блоге в октябре 2018 года в своей экспериментальной версии Blazor 0.6.0, которая теперь доступна:

В прошлом месяце на .NET Conf мы объявили, что решили продвигать серверную модель Blazor как часть ASP.NET Ядро в .NET Core 3.0. Около половины пользователей Blazor указали, что будут использовать серверную модель Blazor, и ее поставка в .NET Core 3.0 сделает ее доступной для производственного использования. В рамках интеграции компонентной модели Blazor в ASP.NET Ядро мы решили дать ему новое название, чтобы отличать его от возможности запуска.СЕТЬ в браузере: компоненты Razor.

Это также обсуждается подробнее в ASP.NET Обновления ядра в блоге .NET Core 3.0 Preview 2.

19 февраля: Сложно назвать…

Вероятно, из-за возникшей путаницы название компонентов Razor для Blazor на стороне сервера было расширено до ‘ASP.NET Компоненты Core Razor’. Об этом упоминается в примечаниях к выпуску Blazor 0.8.0:

Blazor на стороне сервера теперь ASP.NET Компоненты Core Razor в .NET Core 3.0 Как было недавно объявлено, серверный Blazor теперь поставляется как ASP.NET Компоненты Core Razor в .NET Core 3.0. Мы интегрировали компонентную модель Blazor в ASP.NET Ядро 3.0 и переименовал его в компоненты Razor. Blazor 0.8.0 теперь построен на компонентах Razor и позволяет размещать компоненты Razor в браузере на WebAssembly.

Апрель 2019: возврат к Blazor на стороне сервера

В апреле 2019 года серверная часть Blazor вышла в официальный предварительный просмотр, и в рамках этого было возвращено название серверной части Blazor:

Упрощение именования и управления версиями

Некоторое время мы использовали терминологию Razor Components в некоторых случаях и Blazor в других случаях. Оказалось, что это сбивает с толку, поэтому, после многочисленных отзывов сообщества, мы решили отказаться от названия ASP.NET Основные компоненты Razor и вместо этого вернитесь к Blazor на стороне сервера имен.

Это подчеркивает, что Blazor представляет собой единую модель клиентского приложения с несколькими моделями хостинга:

  • Серверный Blazor запускается на сервере через SignalR
  • Клиентский Blazor выполняется на стороне клиента в WebAssembly

… но в любом случае, это одна и та же модель программирования. Одни и те же компоненты Blazor могут быть размещены в обеих средах.

Обратите внимание, что в приведенном выше описании вообще нет упоминания о компонентах Razor, теперь у нас есть две разные модели размещения Blazor (на стороне клиента и на стороне сервера) в качестве способов доставки компонентов Blazor в браузер.

Сентябрь 2019 Возвращение «Компонентов Razor»

В примечаниях Дэна Рота к выпуску Blazor и .NET Core для следующих нескольких версий термин «Компоненты Razor» вообще больше не упоминается до .Предварительный просмотр NET Core 3.0 9 когда этот термин снова появится в названии «прототипа платформы модульного тестирования компонентов Razor».

Май 2020 «Компоненты Razor» = «Компоненты Blazor». Представляем «Blazor Server» и «Blazor WebAssembly»

К тому времени, когда мы доберемся до мая 2020 года, компоненты Razor и Blazor теперь используются как синонимы друг для друга, и названия для двух моделей хостинга эволюционировали.

В блоге Blazor WebAssembly 3.2.0, который теперь доступен, это описывается следующим образом (мой акцент):

Компоненты Blazor затем могут быть размещены различными способами для создания вашего веб-приложения. Первый поддерживаемый способ называется Blazor Server. В серверном приложении Blazor компоненты запускаются на сервере с использованием .NET Core.

И…

Blazor WebAssembly теперь является вторым поддерживаемым способом размещения ваших компонентов Blazor: на стороне клиента в браузере с использованием среды выполнения .NET на основе WebAssembly.

Итак .. термин «Компоненты Razor» официально мертв, верно?

Было бы намного проще, если бы это было … похоже, что ‘Компонент Blazor’ был бы более естественным. Но нет, из раздела компонентов официальной документации:

Компоненты в Blazor формально называются компонентами Razor.

Комментарии:

1. О, это сумасшедшее именование MSFT… Снова…