logo标签列表

Razor组件与Blazor的区别

asp.net-corerazorblazor
19

我有些困惑 Razor 组件和 Blazor 有什么不同，哪个更好，在最新的 .NET Core 3.0 预览版 3 中，它们被添加到了 Razor 组件中。

Razor 组件的改进：

  • 单项目模板
  • 新的 .razor 扩展名
  • 端点路由集成
  • 预渲染
  • 在 Razor 类库中使用 Razor 组件
  • 改进的事件处理
  • 表单和验证
Razor组件是Blazor的一部分... - DavidG
这是一篇来自Scott Hanselman的精彩博客文章：https://www.hanselman.com/blog/WhatIsBlazorAndWhatIsRazorComponents.aspx - AdrienTorris
3个回答
31

本质上有三个部分需要理解。

Razor Components

这是核心、独立进程组件模型的名称，最初是为了 Server-side Blazor 的首次发布而于 2018 年 7 月创建的。

Razor Components 是框架的核心，包含以下所有内容。

  • 参数
  • 事件处理
  • 数据绑定
  • 路由
  • 依赖注入
  • 布局
  • 模板化
  • 级联值

Server-side Blazor

这是 Razor Components 在 ASP.NET Core 上运行的服务器端托管模型。该版本在服务器上托管 Razor Components 模型。它使用一个小型运行时将 UI 事件从浏览器发送到服务器。一旦被 Razor Components 处理，任何 UI 更新都会从服务器发送回浏览器，运行时会处理更新 DOM。所有通信都通过 SignalR 连接处理，包括 JS 交互调用也是这样处理的。

Client-side Blazor

这是 Razor Components 的客户端托管模型。

在此模型中，一切都在浏览器中托管。Mono 编译为 WebAssembly 是 .NET 运行时。在其上层是 Razor Components，最后是应用程序。

这种架构的优点在于，理论上添加到Razor组件中的任何功能都应该可用于两种托管模型。但实际情况并非总是如此。

哪种更好？

这取决于你想做什么。

客户端Blazor最大的缺点是下载大小。这可能会排除很多开发人员使用它的可能性。下载容易达到几个MB，如果有人试图在连接缓慢的移动设备上查看您的应用程序，他们不会有良好的体验。然而，值得注意的是，在第一次下载后，大部分内容都被缓存，因此后续的加载只需几百KB。

客户端Blazor的调试体验目前也非常简单。这意味着作为开发人员在其上开发可能时有挑战性的。

服务器端Blazor在调试方面拥有更好的开发体验。应用程序下载速度更快，仅在进行任何缓存之前就已经有了数百KB的大小。

缺点可能是可扩展性。但这将严重依赖于你期望的并发用户数量。因为这种模型使用SignalR，所以你的应用程序将具有并发连接的最高限制。但是，你可以通过插入到Azure SignalR来管理这一点，以允许更多的连接到你的应用程序。

总的来说，Razor Components的两种托管模型都有很长的路要走。虽然客户端Blazor在认证方面可能处于更好的位置，但两者的认证故事都处于早期阶段。路由引擎仍然受限，表单和验证也刚刚发布了第一个版本，还有待改进。

需要记住的另一件事是，很容易在这些模型之间切换。因此，无论你做出什么决定，你都不会被束缚。甚至将在框架中内置一种切换方式，所以现在做的任何事情都不会浪费。

如有任何问题，请问。希望这能帮到您。

谢谢Chris。对于像ERP这样的大系统，您更喜欢Blazor还是Razor Components？ - user3903484
这里是答案。看起来，在Blazor和RC之间切换非常容易。如果您观看链接的视频，您会看到这一点。演讲者在两者之间切换，因为他的东西是以Balzor而不是RC开始的。 - AndrasCsanyi
非常好的回答，但已经不是最新的了。从Razor Components更名为Server-Side Blazor的服务器端托管模型在ASP.NET Core 3.0 Preview 4中发布。详情请参见此处。如有可能，请更新。 - Guilherme
1
@Guilherme 我已经更新了答案，以反映来自Preview 4的更改。 - Chris Sainty
延迟也是服务器端 Blazor 的一个潜在问题。每次交互都必须往返于服务器，因此即使是中等程度的延迟也可能导致表单输入和菜单等 UI 令人沮丧。 - Mani Gandham
14
Razor Components是一个框架，可用于创建单页应用程序（SPA）的网络应用程序。它被分为两种执行模式。当Web应用程序在浏览器上托管和执行时，称为Blazor。 Blazor应用程序使用C#编写，并编译为.NET程序集。它们由Mono运行时作为.NET程序集在浏览器上执行和运行，而Mono本身则编译为Web Assembly。
第二种执行模式是服务器端。也就是说，您的Web应用程序在服务器上执行，而不是在浏览器上执行。请注意，在此处运行时环境不是Mono Web Assembly，而是Asp.net Core运行时。这称为服务器端Blazor，但术语Razor Components也可以使用，以便让混淆的人感到困惑。原因是历史上如此：一开始，只有运行在浏览器上的Blazor。但后来出现了一个想法，即Web应用程序可以在服务器上运行，并且仅通过SignalR将差异发送到浏览器。在服务器上运行Web应用程序比在浏览器上运行要容易得多，开发人员可以使用许多他无法在浏览器上使用的元素，例如调试等。由于这种可能性的存在，Asp.Net将Blazor框架重命名为Razor Components，您可以将其视为构建Blazor的超级结构。这就是混淆的原因。我们可以如下强调它们之间的区别：
Razor Components --> Blazor（前端；浏览器）
Razor Components --> Razor Components（服务器端Blazor）

我知道这可能会让人感到困惑，但它就是这样...

关于哪种更好的问题，我只能说这取决于您的要求。每种执行模式都有其优点和缺点。Blazor应用程序更适合在互联网上作为公共网站运行，而服务器端Blazor应用程序最适合用于内部网作为企业网站。

您展示的列表与Razor组件框架有关。目前有些改进仅与Blazor相关，而其他改进则与服务器端Blazor相关。只有一种方法可以知道哪种是哪种：学习Razor组件。学习它需要时间，比Angular少，尤其是如果您是.Net开发人员，但它仍然需要一些投资。

希望这有所帮助... 我稍后会改进它，但如果您有具体问题，请不要犹豫问我...

谢谢您，艾萨克。对于像ERP这样的大系统，您更喜欢使用Blazor还是Razor Components？ - user3903484
@user3903484，请将此评论发布为新问题，以便我可以适当地回答。 - enet
Blazor是一个框架，您可以使用它创建SPA Web应用程序。 - EKanadily
5
您有权感到困惑，因为命名已经发生了很多变化。当您编写原始问题时，Blazor团队最近将“服务器端Blazor”更名为“Razor组件”。幸运的是，现在已经放弃了这个名称，有关时间轴的更多信息请参见下文。
对于任何发现答案中的命名约定与他们在旧博客文章中所读到的不符的人，值得知道的是，“Razor组件”的含义多次发生了变化。
这也可能有助于像我一样从一开始就使用Blazor并确信名称已更改的人！
简而言之，命名在预发布期间发生了很大变化。 Microsoft和Blazor团队为尝试提出清晰的名称并愿意在需要时进行更改而获得赞誉。但是，这在旧文章中留下了混合命名约定的遗产，并且一些Blazor老手有时会使用旧的命名约定。
截至2020年9月写作时，在Blazor 3.2版本中，官方命名约定是：

Blazor 命名的激动人心的历史

2018年10月：“Razor Components” 成为“Blazor Server Side”的新名称

当 Blazor 0.6.0 发布时，决定将服务器端 Blazor 正式命名为“Razor Components”。

丹·罗斯特在他2018年10月的博客文章中宣布Blazor 0.6.0实验版本现已推出，讨论了这个问题：

我们在.NET Conf上宣布，我们决定将Blazor服务器端模型作为ASP.NET Core的一部分发布到.NET Core 3.0中。约有一半的Blazor用户表示他们将使用Blazor服务器端模型，并将其发布到.NET Core 3.0中，以供生产使用。作为将Blazor组件模型集成到ASP.NET Core中的一部分，我们决定给它一个新名称，以区别于在浏览器中运行.NET的能力：Razor Components。

这也在.NET Core 3.0预览版2中的ASP.NET Core更新博客文章中更详细地讨论了。

2月19日：命名很难...

由于混淆的原因，服务器端Blazor的Razor组件名称被扩展为“ASP.NET Core Razor Components”。这在Blazor 0.8.0 release notes中提到：

现在，在.NET Core 3.0中，服务器端Blazor被称为ASP.NET Core Razor Components。正如最近宣布的那样，服务器端Blazor现在作为ASP.NET Core Razor Components在.NET Core 3.0中发布。我们已将Blazor组件模型集成到了ASP.NET Core 3.0中，并将其重命名为Razor Components。 Blazor 0.8.0现在基于Razor Components构建，并使您能够在WebAssembly上在浏览器中托管Razor Components。

2019年4月：切换回服务器端Blazor

在2019年4月Blazor服务器端进入官方预览版的一部分，服务器端Blazor的命名被切换回来：

简化命名和版本控制

一段时间以来，我们在某些情况下使用了Razor Components这个术语，在其他情况下则使用Blazor。这被证明是令人困惑的，因此根据社区的反馈，我们决定放弃ASP.NET Core Razor Components的名称，改回Server-side Blazor。

这强调了Blazor是一个具有多个托管模型的单一客户端应用程序模型：

  • Server-side Blazor通过SignalR在服务器上运行
  • Client-side Blazor在WebAssembly上在客户端运行

...但无论哪种方式，它都是相同的编程模型。相同的Blazor组件可以在两个环境中托管。

请注意，在上述描述中根本没有提到Razor Components，现在我们有两种不同的Blazor托管模型（客户端和服务器端），作为向浏览器传递Blazor组件的方式。

2019年9月'Razor Components'的回归

丹·罗斯针对未来几个版本的 Blazor 和 .NET Core 发布的更新记录再也没有提到“Razor Components”的术语，直到 .NET Core 3.0 预览版 9，该术语再次出现在“Razor 组件单元测试框架原型”的名称中。

2020 年 5 月，“Razor Components” = “Blazor Components”。介绍“Blazor Server”和“Blazor WebAssembly”

到了 2020 年 5 月，Razor Components 和 Blazor Components 现在被用作相互换用的同义词，并且两个托管模型的命名已经发生了变化。

Blazor WebAssembly 3.2.0 现已发布 博客如下所述（我强调）：

Blazor组件可以以不同的方式托管以创建您的Web应用程序。第一种支持的方式称为Blazor Server。在Blazor Server应用程序中，组件在服务器上使用.NET Core运行。

而且...

Blazor WebAssembly现在是第二种支持的托管Blazor组件的方式：在浏览器中使用基于WebAssembly的.NET运行时进行客户端托管。

所以，“Razor组件”这个术语已经正式死亡了，对吗？

如果是这样就好了...看起来“Blazor组件”更加自然合适。但是，根据官方文档中的组件部分:

在Blazor中，组件正式被称为Razor组件。

2
哦，那个疯狂的微软命名方式...又来了... - Rodion Mostovoi
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接