0 视频及可视化解释
![enter image description here](https://istack.dev59.com/jTkEk.webp)
我决定制作一个视频,因为有关Blazor的几个问题被提出(也在其他论坛上),这种格式对我来说似乎更好,可以可视化差异-而不是阅读我的(更长)解释。与我的第一篇帖子相比,视频包含了稍微改进的版本(文本帖子也已更新)。这是我用这种格式制作的第一个视频,所以欢迎任何反馈。如果您喜欢阅读经典文本而没有太多可视化,请查看以下部分的内容。当然,没有我制作的演示文稿,但基本信息内容是相同的。
1. 什么是传统的多页面站点或应用程序?
首先,您需要基本了解传统网站/应用程序的工作原理:对于每个调用/请求,您向服务器发送请求,服务器响应整个页面的完整HTML。这可以像使用ASP.NET Core MVC和Razor模板或Razor Pages一样动态生成,甚至可以使用PHP、Java、Python等其他技术。假设您有一个显示预览的文章列表。
为了说明这一点,假设您有一个显示预览的文章列表(例如博客文章)。当用户单击“全部阅读”时,通常有两种方法可以在传统的Web应用程序中实现此目标:
1. 加载类似/view-article?id=123的页面,其中发生了以上情况:加载文章页面的整个HTML DOM
2. 使用JavaScript进行Ajax请求,从类似/api/get-article?id=123的API中加载所需内容,并操作DOM以在所需位置显示它
没有JavaScript,传统站点不具有交互性。这意味着:页面加载和呈现后,就不会再发生任何事情-除非用户通过单击链接加载另一个页面(带有整个DOM)-因此,它被称为“多页面”应用程序。
您可能更喜欢第二种方法,因为它更快并节省资源:而不是重新呈现整个页面(其中只有一部分已更改),您留在该页面并仅加载所需的新信息(例如此示例中的文章内容)。特别是在具有许多要加载和呈现的资源的大型页面上,JavaScript方法对用户来说感觉要快得多。
如果您希望传统页面具有交互性,则需要JavaScript。例如,您可以添加一个ajax调用到某个API,当用户单击按钮时,它将显示一些数据,而无需重新加载整个页面。
简而言之,我们可以说,大部分工作都在服务器端完成。
2. 与单页应用程序(SPA)有何区别?
SPAs只有一个完整的HTML页面,当你通过点击文章等方式导航到页面时,会加载JavaScript应用程序来处理交互。如果用户点击文章,则不会从服务器获取完整的HTML文档!相反,它仅获取已更改的部分,例如文章。其他所有内容(例如导航栏、页脚、小部件等)都将保留-与多页面应用程序相反,在这种情况下,如果没有使用js/ajax,则可能会重新加载。
通常,你会在其中使用模块化组件和双向数据绑定。这意味着一个变量与某个HTML元素相关联。当变量发生更改时,元素会自动显示新值。在传统应用程序中,您需要手动创建事件处理程序来处理此类操作。可以将其视为使用vanilla JavaScript持续开发单个页面应用程序,在那里需要更多的手动工作才能实现诸如数据绑定之类的东西。
对于用户而言,SPA通常比浏览多页面应用程序上的页面更快。
简而言之,我们可以说,大多数工作都在用户浏览器中的客户端执行。服务器只提供静态资源(html、js、css),并提供API以从数据库中获取条目或保存它们。
Blazor应用程序实际上是SPA。但与其他框架的主要区别在于,Blazor让你使用C#代码控制客户端和服务器端。为了展示这一优势,让我们看看其他SPA框架(如Angular):可以在ASP.NET Core中构建一个Angular SPA。在这种情况下,您使用TypeScript在Angular中编写客户端代码。如果需要访问数据,则它将向C#的ASP.NET Core服务器进行API调用。类似地,在其他框架(如React)中也是如此,只不过使用JavaScript而不是TypeScript。
这使得在这两个方面之间共享代码变得困难:如果你有一个文章模型,它需要在服务器上使用C#和在客户端上使用TypeScript进行定义。而在Blazor中,你只需在C#中定义一次并在两个站点上重复使用。换句话说:你只需编写C#,而不必担心JavaScript*。
*这是Blazor背后的基本思想:在整个应用程序中都使用C#,而无需JavaScript作为第二项技术。但值得一提的是,你需要使用Blazor组件来实现这一点。如果还需要某个尚未转移到Blazor的库,则仍然需要处理一些JS。但是仍然存在诸如数据绑定之类的好处。在整个纯JS堆栈上使用它需要付出一些工作,因此我建议从提供Blazor组件的UI库开始使用。
现在你已经了解了基础知识,需要在两种风味之间进行选择:Blazor WebAssembly和Blazor Server。
Blazor WebAssembly
![enter image description here](https://istack.dev59.com/8wEG9.webp)
作为其名称所示,它基本上使用
WebAssembly在浏览器中直接运行您的C#浏览器。它需要一个
相对较新的浏览器,并且尚未在所有平台/浏览器上得到支持。同时,像Chromium或Safari这样的主要引擎
尚未完全支持所有标准化功能。
假设您有一个带有C#代码处理程序的按钮,如下所示:
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
IncrementCount
是一个C#方法。该代码已传输到客户端并将在浏览器中执行。可以将其想象为浏览器内的.NET Core运行时,类似于Silverlight,但没有任何外部插件。甚至不需要在服务器端安装ASP.NET Core!它可以从任何Web服务器提供,只要您不需要来自服务器端的DB等内容。这使得应用程序变得更大(至少在第一次加载时变慢)。
示例Visual Studio模板的大小超过17兆字节!通过压缩,可以将其减小到7兆字节-对于一个hello world应用程序来说仍然很大。通过发布应用程序的发行版,可以将其降至约7 MB,并使用gzip可达到2.4 MB。
至少后续请求会更快。这些DLL文件存储在浏览器缓存中,避免了进一步的请求。
但它也可以离线使用(至少主逻辑不需要API调用)。因此,有时称为真正的SPA-与Angular、React和其他客户端框架相似。
由于WebAssembly的使用,调试可能会更加困难,目前仅支持基于Chromium的浏览器。
不知道WebAssembly?它是一个相对较新的开放标准,生成字节码以改善加载和执行时间,以实现更强大的Web应用程序-独立于语言。您不必使用特定的语言(如JavaScript):由于生成了字节码,也可以使用其他语言,如C ++或Rust。
简而言之,WebAssembly可以被视为功能丰富的Web应用程序的下一代JavaScript,其中Blazor WebAssembly是C#实现。由于浏览器运行时,这里有一些无法使用的API。例如,像sockets或I/O访问(如File.Open或File.Write)。
Blazor Server
![enter image description here](https://istack.dev59.com/y9FnE.webp)
该应用程序运行在服务器上,只是使用SignalR Websockets将输出传输到浏览器(例如单击事件的结果,增加另一个HTML元素中的某个计数器)。这使得应用程序更小、更快,但需要更多的服务器资源,因为您在服务器上有一个SignalR连接和它的虚拟DOM - 这使得它在大型设置中更难扩展。
另一方面,这减少了客户端的要求:他们不需要支持WASM,因此它可以运行在旧浏览器或带有受限制的WASM支持的低端设备上。但由于每个操作都以SignalR调用结束,如果需要离线支持,则应选择Blazor WebAssembly而不是Blazor Server。
应该选择什么?
这取决于您的需求,如上所述。例如,如果需要离线支持,则Blazor Server不是一个好选择。如果您不确定,我会选择Blazor Server,并且只有在计划部署非常大的应用程序时才真正担心这个问题。
在我看来,Blazor Server目前更加平稳和灵活。 Blazor Server也比WebAssembly更稳定。当WebAssembly进一步发展并得到更广泛的支持时,这个建议可能会改变。
但在这种情况下,您可以稍后迁移!
Blazor WebAssembly和Server均使用Razor组件。这意味着:您可以在两者之间进行更改,而无需重新编写整个代码。当从Blazor Server迁移到Blazor WebAssembly时,只需要进行一些数据调用之类的迁移工作。原因是,Blazor WASM完全在浏览器中运行,因此您需要像ASP.NET Core API项目这样的服务器部分来处理它们。
进一步信息
我推荐阅读官方文档中的
Introduction to ASP.NET Core Blazor。其他章节描述了有关平台的大量信息并提供教程。它们详细介绍了诸如
data binding或
event-handling之类的主题,并通过示例进行说明。我在此为基本概述而保持简短。
另请参见:
Blazor WebAssembly 3.2.0和
ASP.NET Core 5。