剃刀组件vs剃刀 [英] Razor components vs Blazor

问题描述

我很困惑Razor组件和Blazor之间的区别是什么，哪个更好，在最新版本的.NET Core 3.0 Preview 3中，将那些添加到Razor组件中

剃刀组件的改进:

• 单个项目模板
• 新的.razor扩展名
• 端点路由集成
• 预渲染
• 剃刀类库中的剃刀组件
• 改进的事件处理功能
• 表格和验证

解决方案

基本上，有3个部分需要理解.

剃刀组件

这是早在2018年7月为服务器端Blazor的第一版创建的核心，进程外组件模型的名称.

Razor组件是框架的核心，包含以下所有内容.

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

服务器端Blazor

这是在ASP.NET Core上运行的Razor组件的服务器端托管模型.此版本在服务器上托管Razor组件模型.它使用小的运行时将UI事件从浏览器发送到服务器.一旦由Razor Components处理，所有UI更新都将从服务器发送回浏览器，并且运行时将处理DOM更新.所有这些通信都是通过SignalR连接进行的.甚至JS互操作调用都是以这种方式处理的.

客户端Blazor

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

在此模型中，所有内容都托管在浏览器中. .NET运行库是编译为WebAssembly的Mono.最重要的是Razor Components，然后是应用程序.

关于此体系结构的一件好事是，从理论上讲，添加到Razor组件的任何功能都应可用于两个托管模型.尽管实际上，并非总是如此.

有什么更好的方法?

这在很大程度上取决于您想做什么.

客户端Blazors最大的缺点是其下载大小.仅此一项就可以排除许多开发人员.下载很容易就变成了多个MB，如果有人试图在连接速度慢的移动设备上查看您的应用程序，他们将不会有很好的体验.但是，值得注意的是，第一次下载后会缓存大量内容，因此后续加载可能只有几百个kb.

客户端Blazors调试经验现在也很原始.这意味着作为开发人员进行开发有时可能会充满挑战.

在调试方面，服务器端Blazor具有更好的开发人员经验.该应用程序的下载速度更快，并且只有几百kb的大小，才可以进行任何缓存.

缺点是潜在的可扩展性.但这在很大程度上取决于您期望的并发用户数.由于此模型使用SignalR，因此您的应用将对并发连接有最高限制.但是，您可以通过插入Azure SignalR来管理此操作，以允许与您的应用程序进行更多数量的连接.

最终，两个Razor Components托管模型还有很长的路要走.尽管可以说客户端Blazor处于更好的位置，但两者的认证故事还处于初期.路由引擎仍然受到限制，表单和验证才刚刚发布，并且还有很多工作要做.

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

任何问题，请询问.但我希望这会有所帮助.

I'm confused whats different between Razor components and Blazor and which is better and in the last release .NET Core 3.0 Preview 3 the add those to Razor Components

Razor Components improvements:

• Single project template
• New .razor extension
• Endpoint routing integration
• Prerendering
• Razor Components in Razor Class Libraries
• Improved event handling
• Forms & validation

解决方案

Essentially there are 3 parts to understand.

Razor Components

This is the name for the core, out of process, component model which was created back in July 2018, for the first release of Server-side Blazor.

Razor Components is the core of the framework and contains all the following things.

• Parameters
• Event handling
• Data binding
• Routing
• Dependency injection
• Layouts
• Templating
• Cascading values

Server-side Blazor

This is the server-side hosting model, running on ASP.NET Core, for Razor Components. This version hosts the Razor Components model on the server. It uses a small runtime to send UI events from the browser to the server. Once processed by Razor Components, any UI updates get sent back from the server to the browser and the runtime handles updating the DOM. All this communication is handled via a SignalR connection. Even JS interop calls are handled this way.

Client-side Blazor

This is the client-side hosting model for Razor Components.

In this model, everything is hosted in the browser. Mono, compiled to WebAssembly, is the .NET runtime. On top of this sits Razor Components and then finally the application.

The great thing about this architecture is that any feature added to Razor Components should, in theory, be available to both hosting models. Although in reality, this is not always the case.

What's better?

That very much depends on what you want to do.

Client-side Blazors biggest drawback is its download size. This alone could rule it out for many developers. Downloads are easily into multiple MBs which if someone is trying to view your app on a mobile with a slow connection, they are not going to have a great experience. However, it's worth noting that after the first download a lot of the content is cached so subsequent loads can be a few 100kb.

Client-side Blazors debugging experience is very primitive right now as well. Which means working on it as a developer can be challenging at times.

Server-side Blazor has a much nicer developer experience in terms of debugging. The app is much faster to download and only has a size of a few 100kb before any caching takes place.

The downside is potentially scalability. But this will very much depend on the number of concurrent users you are expecting. Because this model uses SignalR your app will have a top limit on concurrent connections. But, you can manage this by plugging into Azure SignalR to allow a far greater number of connections to your app.

Ultimately, both hosting models of Razor Components have a long way to go. The authentication stories for both are in very early days, although client-side Blazor is arguably in a better place. The routing engine is still limited, forms and validation have only just had it's first release and there is still work to do.

Another thing to keep in mind is that it is possible to swap between the models pretty easily. So whatever decision you make you're not tied into it. There will even be a way of doing this built into the framework at some point so nothing you do now will be wasted.

Any questions, please ask. But I hope this helps.

这篇关于剃刀组件vs剃刀的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！