Blazor 应用可以通过以下方式之一进行托管:
- WebAssembly 上浏览器中的客户端。
- ASP.NET Core 应用中的服务器端。
Blazor WebAssembly 应用
Blazor WebAssembly 应用使用基于 WebAssembly 的 .NET 运行时在浏览器中直接执行。 Blazor WebAssembly 应用的工作方式与前端 JavaScript 框架(如 Angular 或 React)类似。 但是,而不是编写 JavaScript,而是编写 C# 。 .NET 运行时与应用、应用程序集和任何必需的依赖项一起下载。 不需要浏览器插件或扩展。
下载的程序集是正常的 .NET 程序集,就像在任何其他 .NET 应用中一样。 由于运行时支持 .NET Standard,因此可以将现有的 .NET Standard 库用于应用 BlazorWebAssembly 。 但是,这些程序集仍将在浏览器安全沙盒中执行。 某些功能可能会引发 PlatformNotSupportedException,如尝试访问文件系统或打开任意网络连接。
应用加载时,启动 .NET 运行时并指向应用程序集。 应用启动逻辑运行,并呈现根组件。 Blazor 根据组件的呈现输出计算 UI 更新。 然后应用 DOM 更新。
Blazor WebAssembly 应用纯粹在客户端运行。 此类应用可以部署到静态站点托管解决方案,例如 GitHub Pages 或 Azure 静态网站托管。 服务器上根本不需要 .NET。 与应用部分的深层链接通常需要服务器上的路由解决方案。 路由解决方案将请求重定向到应用的根目录。 例如,可以使用 IIS 中的 URL 重写规则来处理此重定向。
若要获得 Blazor 的所有优势以及全堆栈 .NET Web 开发的好处,请使用 ASP.NET Core 托管您的 BlazorWebAssembly 应用。 通过在客户端和服务器上使用 .NET,可以轻松共享代码,并使用一组一致的语言、框架和工具生成应用。 Blazor 提供了方便的模板,用于设置包含 BlazorWebAssembly 应用和 ASP.NET 核心主机项目的解决方案。 生成解决方案后,由应用生成的静态文件 Blazor 已由配置好回退路由的 ASP.NET Core 应用托管。
Blazor 服务器应用程序
请回顾Blazor体系结构讨论,Blazor组件将其输出呈现到一个名为RenderTree
的中间抽象中。 然后,框架 Blazor 将呈现的内容与之前呈现的内容进行比较。 将差异应用于 DOM。
Blazor 组件根据呈现的输出的应用方式进行去耦。 因此,组件本身不必与更新 UI 的进程在同一进程中运行。 事实上,他们甚至不必在同一台计算机上运行。
在 Blazor 服务器应用中,组件在服务器上运行,而不是在浏览器中的客户端运行。 浏览器中发生的 UI 事件通过实时连接发送到服务器。 事件被分派到正确的组件实例。 组件呈现后,计算后的 UI 差异被序列化并发送到浏览器,然后应用于 DOM。
如果您使用过 ASP.NET AJAX 和Blazor控件,那么服务器托管模型可能会听起来很熟悉。 控件 UpdatePanel
负责在页面上发生触发事件时,应用部分页面更新。 触发时,UpdatePanel
请求部分更新,然后在无需刷新页面的情况下应用该更新。 使用 ViewState
管理 UI 的状态.
Blazor 服务器应用在应用需要与客户端建立活动连接时略有不同。 此外,所有 UI 状态都保留在服务器上。 除了这些差异之外,这两种模型在概念上是相似的。
如何选择正确的 Blazor 托管模型
如托管模型文档中所述Blazor,不同的Blazor托管模型之间需要权衡各自的优缺点。
托管 BlazorWebAssembly 模型具有以下优势:
- 没有 .NET 服务器端依赖项。 下载到客户端后,应用将完全正常运行。
- 完全利用客户端资源和功能。
- 工作将从服务器卸载到客户端。
- 无需 ASP.NET 核心 Web 服务器来托管应用。 无服务器部署方案是可能的(例如,从 CDN 提供应用)。
托管模型的缺点 BlazorWebAssembly 如下:
- 浏览器功能限制应用。
- 需要客户端硬件和软件支持(例如 WebAssembly 支持)。
- 下载大小较大,应用加载所需的时间更长。
- .NET 运行时和工具支持不太成熟。 例如, .NET Standard 支持和调试存在限制。
相反, Blazor 服务器托管模型具有以下优势:
- 下载大小比客户端应用要小得多,应用加载速度要快得多。
- 应用充分利用服务器功能,包括使用任何 .NET 兼容的 API。
- 服务器上的 .NET 用于运行应用,因此现有的 .NET 工具(如调试)按预期工作。
- 支持瘦客户端。 例如,服务器端应用适用于不支持 WebAssembly 的浏览器,并且在资源受限的设备上运行。
- 应用的 .NET/C# 代码库(包括应用的组件代码)不会提供给客户端。
服务器托管模型的缺点 Blazor 是:
- 更高的 UI 延迟。 每次用户交互都涉及到网络跃点。
- 没有脱机支持。 如果客户端连接失败,应用将停止工作。
- 对于具有许多用户的应用来说,可伸缩性具有挑战性。 服务器必须管理多个客户端连接并处理客户端状态。
- 需要 ASP.NET 核心服务器才能为应用提供服务。 无法实现无服务器部署方案。 例如,无法从 CDN 提供应用。
上述权衡列表可能会令人生畏,但稍后可以更改托管模型。 无论选择何种 Blazor 宿主模型,组件模型 都是相同的。 原则上,同一组件可与任一托管模型一起使用。 应用代码不会更改;但是,最好引入抽象,以便组件保持与模型无关的托管状态。 抽象使应用能够更轻松地采用不同的托管模型。
部署应用
ASP.NET Web 窗体应用通常托管在 Windows Server 计算机或群集上的 IIS 上。 Blazor 应用还可以:
- 作为静态文件或 ASP.NET 核心应用托管在 IIS 上。
- 利用 ASP.NET Core 的灵活性,在各种平台和服务器基础结构上托管。 例如,可以在 Linux 上使用 Blazor 或 Apache 托管应用。 有关如何发布和部署 Blazor 应用的详细信息,请参阅 Blazor托管和部署 文档。
在下一部分中,我们将探讨如何设置 BlazorWebAssembly 和 Blazor 的服务器应用项目。