我们将创建我们的第一个 Blazor 项目。实际上，我们将创建 2 个 blazor 项目。一种使用服务器端托管，另一种使用客户端托管。然后我们将运行这两个项目，并查看它们执行的位置和方式的差异。

在此过程中，我们将了解两种托管模式之间的区别以及每种模式的优缺点

执行以下命令安装Blazor WebAssembly App模板

dotnet new --install Microsoft.AspNetCore.Blazor.Templates::3.2.0-preview1.20073.1
复制代码

你可以从 Visual Studio 中的包管理器控制台或命令提示符执行此命令。

单击此处获取最新的 Blazor WebAssembly 应用程序模板

Blazor 托管模型

Blazor 有两种托管模型，Blazor WebAssembly（客户端托管模型）和Blazor Server（服务器端托管模型）

正如模板名称所暗示的那样，使用 Blazor 服务器应用程序模板创建具有服务器托管模型的 blazor 应用程序，使用 Blazor WebAssembly 模板创建具有客户端托管模型的 blazor 应用程序。

Blazor 服务器与 Blazor WebAssembly

两种项目类型的项目结构和布局没有太大区别。
 

在 Visual Studio 中配置多个启动项目

我们可以在 Visual Studio中将多个项目配置为StartUp 项目。以下是步骤。

右键单击解决方案资源管理器中的解决方案名称，然后选择设置启动项目选项

选择多个启动项目单选按钮。针对要设置为启动项目的每个项目，从“操作”下拉列表中选择“启动”。

Blazor WebAssembly 托管模型

使用这种托管模型，应用程序直接在 WebAssembly 上的浏览器中运行。因此，应用程序所需的一切，即编译后的应用程序、它的依赖项和 .NET 运行时都从服务器下载到客户端浏览器。Blazor WebAssembly 应用程序可以完全在客户端上运行，而无需连接到服务器，或者我们可以选择将其配置为使用 Web API 调用或 SignalR 与服务器交互。

Blazor WebAssembly 托管模型的好处：

Blazor WebAssembly 应用程序可以完全在客户端计算机上运行。因此，在下载应用程序后，不需要连接到服务器。这意味着你的服务器无需 24X7 全天候运行。 

工作从服务器卸载到客户端。正在使用的是客户端资源和功能。

我们不需要成熟的 ASP.NET Core Web 服务器来托管应用程序。我们只需要在某处有一个服务器，它可以将应用程序交付给客户端浏览器。这意味着我们可以将应用程序托管在 Internet 上某个地方的我们自己的服务器上，在云中，作为静态网站在 Azure 上，甚至在 CDN 内容交付网络上。

Blazor WebAssembly 托管的缺点：

第一个请求通常需要更长的时间，因为整个应用程序、它的依赖项和 .NET 运行时必须下载到客户端浏览器。请记住，这只是第一个请求需要比平时更长的时间。如果同一个客户端稍后访问该应用程序，它通常会快速启动，因为浏览器会缓存文件。

由于该应用程序完全在客户端浏览器上运行，因此它仅限于浏览器的功能。

根据应用程序的性质，需要有能力的客户端硬件和软件。例如，从软件的角度来看，至少需要一个支持 WebAssembly 的浏览器。

Blazor 服务器托管模型

使用此托管模型，应用程序在服务器上执行。在客户端和服务器之间建立 SignalR 连接。当客户端上发生事件（例如单击按钮）时，有关该事件的信息将通过 SignalR 连接发送到服务器。服务器处理事件并为生成的 HTML 计算差异。整个 HTML 不会再次发送到客户端，它只是通过 SignalR 连接发送到客户端的差异。然后浏览器更新 UI。由于仅应用差异来更新 UI，因此应用程序感觉更快，对用户的响应也更快。

Blazor 服务器托管模型的优点：

该应用程序加载速度更快，因为下载大小明显小于 Blazor WebAssembly 应用程序

由于应用程序在服务器上运行，因此它可以充分利用服务器功能，包括使用任何与 .NET Core 兼容的 API。

使用该应用程序所需的所有客户端是浏览器。甚至不支持 WebAssembly 的浏览器也可以使用。

更安全，因为应用程序的 .NET/C# 代码不提供给客户端。

Blazor 服务器托管的缺点：

需要一个成熟的 ASP.NET Core 服务器来托管应用程序。无服务器部署方案（例如从 CDN 提供应用程序）是不可能的。

始终需要与服务器的活动连接。这意味着需要保持服务器 24X7 全天候运行。如果服务器关闭，应用程序将停止工作。

由于每个用户交互都涉及到服务器的往返，因此与 Blazor WebAssembly 托管相比，通常存在更高的延迟。

可扩展性可能具有挑战性，尤其是对于拥有众多用户的应用程序，因为服务器必须管理多个客户端连接并处理客户端状态。但是，我们可以通过将 Azure SignalR 服务与 Blazor 服务器应用程序结合使用来克服此可伸缩性问题。此服务允许 Blazor 服务器应用程序通过支持大量并发 SignalR 连接来真正很好地扩展。