Razor 组件与 Blazor
Razor components vs Blazor
我很困惑 Razor 组件和 Blazor 之间有什么不同，哪个更好，在上一个版本 .NET Core 3.0 Preview 3 中将它们添加到 Razor 组件中
Razor 组件改进：
- 单个项目模板
- 新的 .razor 扩展
- 端点路由集成
- 预渲染
- Razor 中的 Razor 组件Class 库
- 改进了事件处理
- 表单和验证
基本上有3个部分需要理解。
剃须刀组件
这是 2018 年 7 月为服务器端 Blazor 的第一个版本创建的核心、进程外组件模型的名称。
Razor 组件是框架的核心，包含以下所有内容。
- 参数
- 事件处理
- 数据绑定
- 路由
- 依赖注入
- 布局
- 模板化
- 级联值
服务器端 Blazor
这是服务器端托管模型，运行 在 ASP.NET 核心上，用于 Razor 组件。此版本在服务器上托管 Razor 组件模型。它使用小型运行时将 UI 事件从浏览器发送到服务器。一旦被 Razor Components 处理，任何 UI 更新都会从服务器发送回浏览器，并且运行时会处理更新 DOM。所有这些通信都是通过 SignalR 连接处理的。甚至 JS 互操作调用也是这样处理的。
客户端 Blazor
这是 Razor 组件的客户端托管模型。
在此模型中，一切都托管在浏览器中。编译为 WebAssembly 的 Mono 是 .NET 运行时。在此之上是 Razor Components，最后是应用程序。
这种架构的伟大之处在于，理论上，添加到 Razor Components 的任何功能都应该适用于两种托管模型。虽然在现实中，情况并非总是如此。
哪个比较好？
这很大程度上取决于你想做什么。
客户端 Blazors 最大的缺点是它的下载大小。仅这一点就可以排除许多开发人员的可能性。下载很容易变成多个 MB，如果有人试图在连接速度较慢的移动设备上查看您的应用程序，他们将不会有很好的体验。但是，值得注意的是，在第一次下载后，很多内容都被缓存了，因此后续加载可能有几百 kb。
客户端 Blazors 调试体验现在也非常原始。这意味着作为开发人员进行工作有时会充满挑战。
服务器端 Blazor 在调试方面拥有更好的开发人员体验。该应用程序的下载速度要快得多，并且在进行任何缓存之前只有几 100kb 的大小。
缺点是潜在的可扩展性。但这在很大程度上取决于您期望的并发用户数。由于此模型使用 SignalR，因此您的应用程序将对并发连接数设置上限。但是，您可以通过插入 Azure SignalR 来管理它，以允许更多数量的应用程序连接。
最终，Razor Components 的两种托管模型还有很长的路要走。两者的身份验证故事都处于早期阶段，尽管客户端 Blazor 可以说处于更好的位置。路由引擎仍然有限，表单和验证才刚刚发布第一个版本，还有很多工作要做。
另一件要记住的事情是，可以很容易地在模型之间进行切换。所以无论你做出什么决定，你都不会被它束缚。甚至会有一种方法在某个时候内置到框架中，所以你现在所做的一切都不会浪费。
有什么问题，欢迎提问。但我希望这会有所帮助。
Razor Components 是一个框架，您可以使用它来创建 SPA Web 应用程序。它分为两种执行模式。在浏览器上托管和执行 Web 应用程序时，它称为 Blazor。 Blazor 应用程序使用 C# 编写并编译为 .NET 程序集。它们在 Mono 运行 时间作为 .NET 程序集在浏览器上执行并 运行，它本身被编译为 Web Assembly。
第二种执行方式是服务器端。也就是说，您的 Web 应用程序是在服务器上执行的，而不是在浏览器上执行的。请注意，这里的 运行time 环境不是 Mono WebAssembly 而是 Asp.net Core 运行 时间。这称为服务器端 Blazor，但也使用术语 Razor Components，因此混淆会让人感到困惑。这样做的原因是历史性的：一开始，浏览器上只有 Blazor 运行ning。但后来出现了一个想法，即 Web 应用程序可以 运行 在服务器上，并且只有差异可以通过 SignalR 发送到浏览器。 运行 服务器上的 web 应用程序比 运行 浏览器上的要容易得多，开发人员可以使用许多他在浏览器上无法使用的元素，例如调试等。因此出于这种可能性，Asp.Net 将 Blazor 框架重命名为 Razor Components，您可以将其视为构建 Blazor 的超级结构。这就是混乱的原因。让我们强调一下这种划分：
Razor 组件 --> Blazor（前端；浏览器）
Razor 组件 --> Razor 组件（服务器端 Blazor）
我知道这是混淆的根源，但就是这样...
至于哪个更好，我只能说这完全取决于你的要求。这些执行模式中的每一种都有其优点和缺点。 Blazor 应用程序更适合 运行 在 Internet 上用作 public 网站，而服务器端 Blazor 应用程序最适合在 Intranet 上用作企业网站。
您显示的列表与 Razor Components 框架有关。目前，一些改进可能仅与 Blazor 相关，而其他改进则与服务器端 Blazor 相关。只有一种方法可以知道哪个是哪个：学习 Razor 组件。学习它需要时间，少于 Angular，特别是如果您是 .Net 开发人员，但它仍然需要一些投资。
希望这对您有所帮助...
我稍后会对此进行改进，但如果您有具体问题，请随时提问...
您完全有权利感到困惑，命名发生了很大变化，当您编写原始问题时，Blazor 团队最近将 'Server Side Blazor' 重命名为 'Razor Components'。谢天谢地，这已经被放弃了，请参阅下面的时间表了解更多信息。
任何发现这里答案中的命名约定似乎与他们在旧博客中阅读的内容不一致的人 posts 值得知道的是 'Razor Components' 的含义随着时间的推移反复改变。
这也可以帮助像我这样从一开始就一直在使用 Blazor 并且确信名称已更改的人！
TL;博士
命名在 pre-release 时期发生了很大变化。感谢 Microsoft 和 Blazor 团队尝试提出清晰的名称并愿意在需要时改回原来的名称。但是，这在旧文章中留下了混合命名约定的遗留问题，一些 Blazor 老手有时会使用旧的命名约定。
在 2020 年 9 月撰写本文时，Blazor 版本为 3.2，the official naming convention 为：
- Blazor Components（正式名称为'Razor Components'）可用于...
- Blazor Server 个应用，或..
- Blazor WebAssembly 应用程序
Blazor 命名的激动人心的历史
2018 年 10 月：'Razor Components' 成为 'Blazor Server Side'
的新名称
当 Blazor 0.6.0 发布时，决定将服务器端 Blazor 正式命名为 'Razor Components'。
Dan Roth 于 2018 年 10 月在他的 Blazor 0.6.0 experimental release now available 博客 post 中讨论了这一点：
We announced last month at .NET Conf that we've decided to move
forward with shipping the Blazor server-side model as part of ASP.NET
Core in .NET Core 3.0. About half of Blazor users have indicated they
would use the Blazor server-side model, and shipping it in .NET Core
3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give
it a new name to differentiate it from the ability to run .NET in the
browser: Razor Components.
ASP.NET Core updates in .NET Core 3.0 Preview 2 博客 post 中也对此进行了更多讨论。
2 月 19 日：命名很难...
可能是由于出现混淆，服务器端 Blazor 的 Razor 组件名称扩展为 'ASP.NET Core Razor Components'。 Blazor 0.8.0 release notes:
中提到了这一点
Server-side Blazor is now ASP.NET Core Razor Components in .NET Core
3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the
Blazor component model into ASP.NET Core 3.0 and renamed it to Razor
Components. Blazor 0.8.0 is now built on Razor Components and enables
you to host Razor Components in the browser on WebAssembly.
2019 年 4 月：切换回 Server-side Blazor
在 April 2019 Blazor server side went into official preview 中，服务器端 Blazor 的命名被切换回：
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other
cases. This has proven to be confusing, so following a lot of
community feedback, we’ve decided to drop the name ASP.NET Core Razor
Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple
hosting models:
- Server-side Blazor runs on the server via SignalR
- Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor
components can be hosted in both environments.
请注意，在上面的描述中根本没有提到 Razor 组件，现在我们有两种不同的 Blazor 托管模型（Client-side 和 server-side）作为将 Blazor 组件交付给浏览器。
2019 年 9 月 'Razor Components'
的 return
Dan Roth 的 Blazor 和 .NET Core 后续几个版本的发行说明不再提及术语 'Razor Components'，直到 .NET Core 3.0 Preview 9 该术语再次以 [=93] 的名称出现=].
2020 年 5 月 'Razor Components' = 'Blazor Components'。介绍 'Blazor Server' 和 'Blazor WebAssembly'
到 2020 年 5 月时，Razor Components 和 Blazor Components 现在被用作彼此的同义词，并且两种托管模型的命名已经演变。
Blazor WebAssembly 3.2.0 now available 博客描述如下（我强调）：
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In
a Blazor Server app, the components run on the server using .NET Core.
还有...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET
runtime.
所以.. 'Razor Components' 这个词正式死了，对吧？
如果它是.. 看起来 'Blazor Component' 会更自然。但是不，来自 Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.
我很困惑 Razor 组件和 Blazor 之间有什么不同，哪个更好，在上一个版本 .NET Core 3.0 Preview 3 中将它们添加到 Razor 组件中
Razor 组件改进：
- 单个项目模板
- 新的 .razor 扩展
- 端点路由集成
- 预渲染
- Razor 中的 Razor 组件Class 库
- 改进了事件处理
- 表单和验证
基本上有3个部分需要理解。
剃须刀组件
这是 2018 年 7 月为服务器端 Blazor 的第一个版本创建的核心、进程外组件模型的名称。
Razor 组件是框架的核心，包含以下所有内容。
- 参数
- 事件处理
- 数据绑定
- 路由
- 依赖注入
- 布局
- 模板化
- 级联值
服务器端 Blazor
这是服务器端托管模型，运行 在 ASP.NET 核心上，用于 Razor 组件。此版本在服务器上托管 Razor 组件模型。它使用小型运行时将 UI 事件从浏览器发送到服务器。一旦被 Razor Components 处理，任何 UI 更新都会从服务器发送回浏览器，并且运行时会处理更新 DOM。所有这些通信都是通过 SignalR 连接处理的。甚至 JS 互操作调用也是这样处理的。
客户端 Blazor
这是 Razor 组件的客户端托管模型。
在此模型中，一切都托管在浏览器中。编译为 WebAssembly 的 Mono 是 .NET 运行时。在此之上是 Razor Components，最后是应用程序。
这种架构的伟大之处在于，理论上，添加到 Razor Components 的任何功能都应该适用于两种托管模型。虽然在现实中，情况并非总是如此。
哪个比较好？
这很大程度上取决于你想做什么。
客户端 Blazors 最大的缺点是它的下载大小。仅这一点就可以排除许多开发人员的可能性。下载很容易变成多个 MB，如果有人试图在连接速度较慢的移动设备上查看您的应用程序，他们将不会有很好的体验。但是，值得注意的是，在第一次下载后，很多内容都被缓存了，因此后续加载可能有几百 kb。
客户端 Blazors 调试体验现在也非常原始。这意味着作为开发人员进行工作有时会充满挑战。
服务器端 Blazor 在调试方面拥有更好的开发人员体验。该应用程序的下载速度要快得多，并且在进行任何缓存之前只有几 100kb 的大小。
缺点是潜在的可扩展性。但这在很大程度上取决于您期望的并发用户数。由于此模型使用 SignalR，因此您的应用程序将对并发连接数设置上限。但是，您可以通过插入 Azure SignalR 来管理它，以允许更多数量的应用程序连接。
最终，Razor Components 的两种托管模型还有很长的路要走。两者的身份验证故事都处于早期阶段，尽管客户端 Blazor 可以说处于更好的位置。路由引擎仍然有限，表单和验证才刚刚发布第一个版本，还有很多工作要做。
另一件要记住的事情是，可以很容易地在模型之间进行切换。所以无论你做出什么决定，你都不会被它束缚。甚至会有一种方法在某个时候内置到框架中，所以你现在所做的一切都不会浪费。
有什么问题，欢迎提问。但我希望这会有所帮助。
Razor Components 是一个框架，您可以使用它来创建 SPA Web 应用程序。它分为两种执行模式。在浏览器上托管和执行 Web 应用程序时，它称为 Blazor。 Blazor 应用程序使用 C# 编写并编译为 .NET 程序集。它们在 Mono 运行 时间作为 .NET 程序集在浏览器上执行并 运行，它本身被编译为 Web Assembly。
第二种执行方式是服务器端。也就是说，您的 Web 应用程序是在服务器上执行的，而不是在浏览器上执行的。请注意，这里的 运行time 环境不是 Mono WebAssembly 而是 Asp.net Core 运行 时间。这称为服务器端 Blazor，但也使用术语 Razor Components，因此混淆会让人感到困惑。这样做的原因是历史性的：一开始，浏览器上只有 Blazor 运行ning。但后来出现了一个想法，即 Web 应用程序可以 运行 在服务器上，并且只有差异可以通过 SignalR 发送到浏览器。 运行 服务器上的 web 应用程序比 运行 浏览器上的要容易得多，开发人员可以使用许多他在浏览器上无法使用的元素，例如调试等。因此出于这种可能性，Asp.Net 将 Blazor 框架重命名为 Razor Components，您可以将其视为构建 Blazor 的超级结构。这就是混乱的原因。让我们强调一下这种划分：
Razor 组件 --> Blazor（前端；浏览器）
Razor 组件 --> Razor 组件（服务器端 Blazor）
我知道这是混淆的根源，但就是这样...
至于哪个更好，我只能说这完全取决于你的要求。这些执行模式中的每一种都有其优点和缺点。 Blazor 应用程序更适合 运行 在 Internet 上用作 public 网站，而服务器端 Blazor 应用程序最适合在 Intranet 上用作企业网站。
您显示的列表与 Razor Components 框架有关。目前，一些改进可能仅与 Blazor 相关，而其他改进则与服务器端 Blazor 相关。只有一种方法可以知道哪个是哪个：学习 Razor 组件。学习它需要时间，少于 Angular，特别是如果您是 .Net 开发人员，但它仍然需要一些投资。
希望这对您有所帮助... 我稍后会对此进行改进，但如果您有具体问题，请随时提问...
您完全有权利感到困惑，命名发生了很大变化，当您编写原始问题时，Blazor 团队最近将 'Server Side Blazor' 重命名为 'Razor Components'。谢天谢地，这已经被放弃了，请参阅下面的时间表了解更多信息。
任何发现这里答案中的命名约定似乎与他们在旧博客中阅读的内容不一致的人 posts 值得知道的是 'Razor Components' 的含义随着时间的推移反复改变。
这也可以帮助像我这样从一开始就一直在使用 Blazor 并且确信名称已更改的人！
TL;博士
命名在 pre-release 时期发生了很大变化。感谢 Microsoft 和 Blazor 团队尝试提出清晰的名称并愿意在需要时改回原来的名称。但是，这在旧文章中留下了混合命名约定的遗留问题，一些 Blazor 老手有时会使用旧的命名约定。
在 2020 年 9 月撰写本文时，Blazor 版本为 3.2，the official naming convention 为：
- Blazor Components（正式名称为'Razor Components'）可用于...
- Blazor Server 个应用，或..
- Blazor WebAssembly 应用程序
Blazor 命名的激动人心的历史
2018 年 10 月：'Razor Components' 成为 'Blazor Server Side'
的新名称当 Blazor 0.6.0 发布时，决定将服务器端 Blazor 正式命名为 'Razor Components'。
Dan Roth 于 2018 年 10 月在他的 Blazor 0.6.0 experimental release now available 博客 post 中讨论了这一点：
We announced last month at .NET Conf that we've decided to move forward with shipping the Blazor server-side model as part of ASP.NET Core in .NET Core 3.0. About half of Blazor users have indicated they would use the Blazor server-side model, and shipping it in .NET Core 3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give it a new name to differentiate it from the ability to run .NET in the browser: Razor Components.
ASP.NET Core updates in .NET Core 3.0 Preview 2 博客 post 中也对此进行了更多讨论。
2 月 19 日：命名很难...
可能是由于出现混淆，服务器端 Blazor 的 Razor 组件名称扩展为 'ASP.NET Core Razor Components'。 Blazor 0.8.0 release notes:
中提到了这一点Server-side Blazor is now ASP.NET Core Razor Components in .NET Core 3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the Blazor component model into ASP.NET Core 3.0 and renamed it to Razor Components. Blazor 0.8.0 is now built on Razor Components and enables you to host Razor Components in the browser on WebAssembly.
2019 年 4 月：切换回 Server-side Blazor
在 April 2019 Blazor server side went into official preview 中，服务器端 Blazor 的命名被切换回：
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other cases. This has proven to be confusing, so following a lot of community feedback, we’ve decided to drop the name ASP.NET Core Razor Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple hosting models:
- Server-side Blazor runs on the server via SignalR
- Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor components can be hosted in both environments.
请注意，在上面的描述中根本没有提到 Razor 组件，现在我们有两种不同的 Blazor 托管模型（Client-side 和 server-side）作为将 Blazor 组件交付给浏览器。
2019 年 9 月 'Razor Components'
的 returnDan Roth 的 Blazor 和 .NET Core 后续几个版本的发行说明不再提及术语 'Razor Components'，直到 .NET Core 3.0 Preview 9 该术语再次以 [=93] 的名称出现=].
2020 年 5 月 'Razor Components' = 'Blazor Components'。介绍 'Blazor Server' 和 'Blazor WebAssembly'
到 2020 年 5 月时，Razor Components 和 Blazor Components 现在被用作彼此的同义词，并且两种托管模型的命名已经演变。
Blazor WebAssembly 3.2.0 now available 博客描述如下（我强调）：
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In a Blazor Server app, the components run on the server using .NET Core.
还有...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET runtime.
所以.. 'Razor Components' 这个词正式死了，对吧？
如果它是.. 看起来 'Blazor Component' 会更自然。但是不，来自 Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.