【问题标题】:Razor components vs BlazorRazor 组件与 Blazor
【发布时间】:2019-07-31 21:14:29
【问题描述】:

我很困惑 Razor 组件和 Blazor 之间有什么不同,哪个更好,在最后一个版本 .NET Core 3.0 Preview 3 中将它们添加到 Razor 组件中

Razor 组件改进:

  • 单个项目模板
  • 新的 .razor 扩展名
  • 端点路由集成
  • 预呈现
  • Razor 类库中的 Razor 组件
  • 改进的事件处理
  • 表单和验证

【问题讨论】:

标签: asp.net-core razor blazor


【解决方案1】:

基本上有3个部分要理解。

剃须刀组件

这是 2018 年 7 月为服务器端 Blazor 的第一个版本创建的核心、进程外组件模型的名称。

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

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

服务器端 Blazor

这是服务器端托管模型,在 ASP.NET Core 上运行,用于 Razor 组件。此版本在服务器上托管 Razor 组件模型。它使用小型运行时将 UI 事件从浏览器发送到服务器。一旦被 Razor 组件处理,任何 UI 更新都会从服务器发送回浏览器,并且运行时会处理更新 DOM。所有这些通信都是通过 SignalR 连接处理的。甚至 JS 互操作调用也是这样处理的。

客户端 Blazor

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

在此模型中,所有内容都托管在浏览器中。编译为 WebAssembly 的 Mono 是 .NET 运行时。在此之上是 Razor 组件,最后是应用程序。

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

什么更好?

这很大程度上取决于你想做什么。

客户端 Blazors 最大的缺点是它的下载大小。对于许多开发人员来说,仅此一项就可以排除它。下载很容易进入多个 MB,如果有人试图在连接速度较慢的移动设备上查看您的应用程序,他们将不会有很好的体验。然而,值得注意的是,在第一次下载后,很多内容都被缓存了,因此后续加载可能只有 100kb。

客户端 Blazors 调试体验现在也非常原始。这意味着作为一名开发人员从事这项工作有时可能具有挑战性。

服务器端 Blazor 在调试方面具有更好的开发人员体验。该应用程序的下载速度要快得多,并且在进行任何缓存之前只有几个 100kb 的大小。

缺点是潜在的可扩展性。但这在很大程度上取决于您期望的并发用户数量。因为此模型使用 SignalR,所以您的应用程序将有并发连接的上限。但是,您可以通过插入 Azure SignalR 来管理此问题,以允许与您的应用建立更多连接。

最终,Razor 组件的两种托管模型都有很长的路要走。两者的身份验证故事都还处于早期阶段,尽管客户端 Blazor 可以说处于更好的位置。路由引擎仍然有限,表单和验证才刚刚发布,还有很多工作要做。

要记住的另一件事是,可以很容易地在模型之间进行交换。所以无论你做出什么决定,你都不会被束缚。在某些时候甚至会在框架中内置一种方法,因此您现在所做的一切都不会浪费。

有任何问题,请追问。但我希望这会有所帮助。

【讨论】:

  • 感谢 Chris,对于像 erp 这样的大型系统,您会更喜欢 Blazor 或 Razor Components
  • Here 就是答案。看起来,在 Blazor 和 RC 之间切换非常容易。如果您通过链接的视频观看,您将看到它。演示者在两者之间切换,因为他的东西是从 Balzor insted of RC 开始的。
  • 很好的答案,但不是最新的。在 ASP.NET Core 3.0 Preview 4 上,服务器端托管模型从 Razor 组件重命名为 Server-Side Blazor。详细信息 here。如果可能,请更新。
  • @Guilherme 我已更新答案以反映预览版 4 的更改。
  • 延迟也是服务器端 Blazor 的一大潜在问题。每个交互都必须往返于服务器,因此即使是适度的延迟也会导致表单输入和菜单等 UI 令人沮丧。
【解决方案2】:

Razor Components 是一个框架,您可以使用它创建 SPA Web 应用程序。它分为两种执行模式。当 Web 应用程序在浏览器上托管和执行时,它称为 Blazor。 Blazor 应用程序使用 C# 编写并编译为 .NET 程序集。它们由 Mono 运行时作为 .NET 程序集在浏览器上执行和运行,而 Mono 运行时本身被编译为 Web 程序集。

第二种执行模式是服务器端。也就是说,您的 Web 应用程序在服务器上执行,而不是在浏览器上执行。请注意,这里的运行时环境不是 Mono Web Assembly,而是 Asp.net Core 运行时。这称为服务器端 Blazor,但也使用了术语 Razor 组件,因此困惑的人会感到困惑。其原因是历史性的:一开始,浏览器上只有 Blazor 运行。但后来出现了一个想法,即 Web 应用程序可以在服务器上运行,并且只能通过 SignalR 将差异发送到浏览器。在服务器上运行 web 应用程序比在浏览器上运行要容易得多,并且开发人员可以使用许多他在浏览器上无法使用的元素,例如调试等。由于这种可能性,Asp.Net 更名为Blazor 框架作为 Razor 组件,您可以将其视为构建 Blazor 的上层结构。这就是混乱的原因。让我们强调一下这个划分:

Razor 组件 --> Blazor(前端;浏览器)

Razor 组件 --> Razor 组件(服务器端 Blazor)

我知道这是混乱的根源,但就是这样......

关于哪个更好的问题,我只能说这完全取决于您的要求。这些执行模式中的每一种都有其优点和缺点。 Blazor 应用程序更适合作为公共网站在 Internet 上运行,而服务器端 Blazor 应用程序最适合作为企业网站在 Intranet 上使用。

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

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

【讨论】:

  • 感谢 Issac,感谢您提供像 erp 这样的大型系统,您更喜欢 Blazor 或 Razor 组件
  • @user3903484,请将此评论作为一个新问题发布,以便我可以适当地回答。
  • 第一句“Razor Components 是一个可以用来创建 SPA Web 应用程序的框架”是错误的。删除“Razor Components”并将其替换为“blazor”。
【解决方案3】:

您完全有权感到困惑,命名发生了很大变化,当您编写原始问题时,Blazor 团队最近将“服务器端 Blazor”重命名为“Razor 组件”。谢天谢地,这已经被放弃了,请参阅下面的时间表了解更多信息。

对于任何发现此处答案中的命名约定似乎与他们在旧博客文章中阅读的内容不一致的人来说,值得知道“Razor Components”的含义随着时间的推移而反复发生变化。

这也可能对像我这样从一开始就使用 Blazor 并确信名称已更改的人有所帮助!

TL;博士

在预发布期间,命名发生了很大变化。感谢 Microsoft 和 Blazor 团队尝试提出清晰的名称并愿意在需要时改回来。但是,这在旧文章中留下了混合命名约定的遗留问题,一些 Blazor 资深人士有时会使用旧的命名约定。

在 2020 年 9 月撰写本文时,Blazor 版本为 3.2,the official naming convention 是:

Blazor 命名的激动人心的历史

2018 年 10 月:“Razor 组件”成为“Blazor 服务器端”的新名称

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

Dan Roth 在 2018 年 10 月的 Blazor 0.6.0 experimental release now available 博客文章中讨论了这一点:

我们上个月在 .NET Conf 上宣布我们决定迁移 将 Blazor 服务器端模型作为 ASP.NET 的一部分进行交付 .NET Core 3.0 中的核心。大约一半的 Blazor 用户表示他们 将使用 Blazor 服务器端模型,并在 .NET Core 中发布 3.0 将使其可用于生产。作为将 Blazor 组件模型集成到 ASP.NET Core 的一部分,我们决定提供 它是一个新名称,以区别于在 .NET 中运行的能力 浏览器:Razor 组件。

ASP.NET Core updates in .NET Core 3.0 Preview 2 博客文章中也对此进行了更多讨论。

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

可能由于出现混淆,服务器端 Blazor 的 Razor 组件名称已扩展为“ASP.NET Core Razor 组件”。 Blazor 0.8.0 release notes中提到了这一点:

服务器端 Blazor 现在是 .NET Core 中的 ASP.NET Core Razor 组件 3.0 正如最近宣布的那样,服务器端 Blazor 现在作为 .NET Core 3.0 中的 ASP.NET Core Razor 组件发布。我们已经集成了 Blazor 组件模型到 ASP.NET Core 3.0 并重命名为 Razor 成分。 Blazor 0.8.0 现在基于 Razor 组件构建并启用 您可以在 WebAssembly 的浏览器中托管 Razor 组件。

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

April 2019 Blazor server side went into official preview 中,服务器端 Blazor 的命名被切换回:

简化命名和版本控制

一段时间以来,我们在某些情况下使用术语 Razor 组件,在其他情况下使用 Blazor 案例。这已被证明是令人困惑的,所以遵循了很多 社区反馈,我们决定放弃名称 ASP.NET Core Razor 组件,并改为返回名称 Server-side Blazor。

这强调了 Blazor 是一个单一客户端应用模型,具有多个 托管模型:

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

...但无论哪种方式,它都是相同的编程模型。相同的布雷泽 组件可以托管在这两种环境中。

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

2019 年 9 月“Razor Components”回归

Dan Roth 的 Blazor 和接下来几个版本的 .NET Core 发行说明根本不再提及“Razor 组件”一词,直到 .NET Core 3.0 Preview 9 再次以“Razor 组件单元测试框架原型”的名义出现该术语.

2020 年 5 月“Razor 组件”=“Blazor 组件”。介绍“Blazor 服务器”和“Blazor WebAssembly”

到 2020 年 5 月,Razor 组件和 Blazor 组件现在已被用作彼此的同义词,并且这两种托管模型的命名已经演变。

Blazor WebAssembly 3.2.0 now available 博客描述如下(我的重点):

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

还有……

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

所以.. 'Razor Components' 这个词正式死了,对吧?

如果是这样,那就容易多了.. 看起来“Blazor 组件”会更自然。但是没有,来自Components section of the official documentation

Blazor 中的组件正式称为 Razor 组件。

【讨论】:

  • 哦,那个疯狂的 MSFT 的命名......再次......
猜你喜欢
  • 2018-07-17
  • 2020-12-10
  • 2019-09-18
  • 2021-12-20
  • 2019-11-15
  • 2020-05-23
  • 1970-01-01
  • 2021-11-23
  • 2021-04-22
相关资源
最近更新 更多