当前位置：文江博客话题详情

Blazor 服务器端与 Blazor WebAssembly 托管

发布于 2025-01-10 08:35:03 字数 329 浏览 0 评论 0原文

我是 Blazor 新手，正在尝试了解不同托管模型之间的差异。

根据我的阅读，我了解到 Blazor 服务器端和 Blazor WebAssembly Hosted 都有服务器端代码，两者都使用 Signal R 与客户端通信。

那么它们之间有什么区别呢？这些的客户端部署在哪里？他们与Server的连接有什么区别？如果 Web 应用程序依次调用第 3 方 Web API，则调用如何路由？

我发现的一个区别在于项目结构。 Blazor 服务器端只有一个项目（带有数据文件夹）。 Blazor WebAssembly Hosted 有 3 个项目（.Server、.Client 和 .Shared）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

山川志 2025-01-17 08:35:03

主要区别在于 .NET 代码的运行位置：对于 Blazor Server，它 100% 在服务器端；而对于 Blazor Server，它是 100% 在服务器端。对于托管 Blazor WASM 应用程序，.NET 代码在服务器和客户端上运行（尽管服务器也可以运行您想要的任何其他语言或框架）。

根据我的阅读，我了解 Blazor 服务器端和 Blazor WebAssembly Hosted 有服务器端代码，...

确实如此，但它看起来不同。

.NET 运行时是 100% 使用 Blazor Server 应用程序的服务器端。客户端使用框架 JS 库与服务器进行通信，但最终，您得到的是一个 .NET 应用程序。
使用 Blazor WASM，您的客户端在浏览器中运行单独的 .NET 运行时。除了客户端 WASM 应用程序之外，托管模型还会生成一个 .NET Web API Server 项目；但是，您可以使用任何后端技术来服务和增强您的客户端应用程序（例如 Node.JS 上的 Express），因为您的客户端与服务器技术无关。

...都使用 Signal R 与客户端通信。

未必。 Blazor Server 需要 Signal R 来不断地与客户端通信和更新，但 Blazor WASM 更加灵活。来自文档：

托管客户端应用程序可以使用各种消息传递框架和协议通过网络与其后端服务器应用程序交互，例如 Web API, gRPC-web 和 SignalR。

同样，Blazor WASM 对于服务器端来说是不可知的。托管模型为您生成服务器端，但从技术上讲您可以使用您想要的任何内容。

这些的客户端部署在哪里？

Blazor Server 不会编译客户端：一旦与应用程序建立连接，它就会利用 Signal R 通过 Web 套接字（或其他不可用的技术）持续将更新推送到客户端。

Blazor WASM 是客户端：当您编译 WASM 项目时，您将得到类似于针对 React 应用程序运行 Webpack 的内容。 Blazor WASM 是一种前端技术，因此它可以作为静态网页的依赖项，也可以通过 Web-API 进行增强和服务，就像托管模型一样。

它们与服务器的连接有什么区别？

同样，Blazor Server 需要 Signal R，而 Blazor WASM 与技术无关：它可以使用 Signal R，但通常您需要的只是标准 HTTP 协议。

如果 Web 应用程序依次调用第 3 方 Web API，则如何路由调用？

这是一个完全不同的问题，但我可以看到其中的困惑。您的 WebAPI 是一个完全独立的应用程序；如果您的 WASM 应用程序发出外部请求，那么它也不会变得更明智。

这些文档提供了以下见解（请注意，这并不区分 WASM 的两种模型，但它仍然适用）：

当创建用于部署的 Blazor WebAssembly 应用程序而无需后端 ASP.NET Core 应用来提供其文件时，该应用程序称为独立 Blazor WebAssembly 应用程序。当创建应用程序以使用后端应用程序进行部署以提供其文件时，该应用程序称为托管 Blazor WebAssembly 应用程序。
Blazor WebAssembly (WASM) 托管模型具有多项优势：
从服务器下载应用程序后，不存在 .NET 服务器端依赖项，因此即使服务器离线，应用程序仍可正常运行。
充分利用客户资源和能力。
工作从服务器转移到客户端。
托管应用程序不需要 ASP.NET Core Web 服务器。 > - 无服务器部署方案是可能的，例如从内容交付网络 (CDN) 提供应用程序。
Blazor WebAssembly 托管模型具有以下限制：
该应用受限于浏览器的功能。
需要强大的客户端硬件和软件（例如 WebAssembly 支持）。
下载大小较大，应用加载时间较长。

与 Blazor 服务器相比：

Blazor Server 托管模型具有多项优势：
下载大小明显小于 Blazor WebAssembly 应用，并且应用加载速度更快。
- 该应用程序充分利用服务器功能，包括使用 .NET Core API。
服务器上的 .NET Core 用于运行应用，因此现有的 .NET 工具（例如调试）可以按预期工作。
支持瘦客户端。例如，Blazor Server 应用可与不支持 WebAssembly 的浏览器以及资源受限的设备配合使用。
不向客户端提供应用的 .NET/C# 代码库（包括应用的组件代码）。
Blazor Server 托管模型具有以下限制：
通常存在较高的延迟。每个用户交互都涉及一个网络跃点。
没有离线支持。如果客户端连接失败，应用程序将停止工作。
扩展具有多个用户的应用需要服务器资源来处理多个客户端连接和客户端状态。
需要 ASP.NET Core 服务器来为该应用提供服务。无服务器部署方案是不可能的，例如通过内容交付网络 (CDN) 提供应用程序。

The primary difference is where your .NET code is running: with Blazor Server, it's 100% server-side; with a hosted Blazor WASM application, .NET code is running on both the server and the client (though the server can run any other language or framework you want too).

From what I read I understand Blazor Server side and Blazor WebAssembly Hosted have server side code, ...

True, but it looks different.

The .NET runtime is 100% server-side with Blazor Server application. A framework JS library is used by the client to communicate with the server, but at the end of the day, you are getting one .NET application.
With Blazor WASM, your client is running a separate .NET runtime in your browser. In addition to the client WASM app, the hosted model generates a .NET Web API Server project; however you could use any backend technology to serve and enhance your client application (e.g. Express on Node.JS) because your client is server technology agnostic.

... both use Signal R to communicate with the Client.

Not necessarily. Blazor Server needs Signal R to continuously communicate and update the client, but Blazor WASM is more flexible. From the docs:

A hosted client app can interact with its backend server app over the network using a variety of messaging frameworks and protocols, such as web API, gRPC-web, and SignalR.

Again, Blazor WASM is agnostic towards your server-side. The hosted model generates a server-side for you, but you could technically use whatever you want.

Where is the client side of these deployed to?

Blazor Server doesn't compile a client-side per-say: once a connection is made to the application, it leverages Signal R to continuously push updates to the client over a web socket (or other technology when that is not available).

Blazor WASM is the client side: when you compile a WASM project, you are getting something similar to running Webpack against a React application. Blazor WASM is a front-end technology, so it can be served as a dependency of a static web page, or it can be augmented and served by a web-api, like with the hosted model.

What difference is in their connection with Server?

Again, Blazor Server requires Signal R, whereas Blazor WASM is technology agnostic: it can be made to use Signal R, but often all you will need is the standard HTTP protocol.

If the Web App in turn calls a 3rd party web API how is the call routed?

This is an entirely different question, but I can see the confusion. Your WebAPI is a totally separate application; your WASM application is none the wiser if it makes external requests.

The docs offer the following insights (note this does not distinguish the two models for WASM, but it still applies):

When the Blazor WebAssembly app is created for deployment without a backend ASP.NET Core app to serve its files, the app is called a standalone Blazor WebAssembly app. When the app is created for deployment with a backend app to serve its files, the app is called a hosted Blazor WebAssembly app.
The Blazor WebAssembly (WASM) hosting model offers several benefits:
There's no .NET server-side dependency after the app is downloaded from the server, so the app remains functional if the server goes offline.
Client resources and capabilities are fully leveraged.
Work is offloaded from the server to the client.
An ASP.NET Core web server isn't required to host the app. > - Serverless deployment scenarios are possible, such as serving the app from a Content Delivery Network (CDN).
The Blazor WebAssembly hosting model has the following limitations:
The app is restricted to the capabilities of the browser.
Capable client hardware and software (for example, WebAssembly support) is required.
Download size is larger, and apps take longer to load.

Versus Blazor Server:

The Blazor Server hosting model offers several benefits:
Download size is significantly smaller than a Blazor WebAssembly app, and the app loads much faster.
-The app takes full advantage of server capabilities, including the use of .NET Core APIs.
.NET Core on the server is used to run the app, so existing .NET tooling, such as debugging, works as expected.
Thin clients are supported. For example, Blazor Server apps work with browsers that don't support WebAssembly and on resource-constrained devices.
The app's .NET/C# code base, including the app's component code, isn't served to clients.
The Blazor Server hosting model has the following limitations:
Higher latency usually exists. Every user interaction involves a network hop.
There's no offline support. If the client connection fails, the app stops working.
Scaling apps with many users requires server resources to handle multiple client connections and client state.
An ASP.NET Core server is required to serve the app. Serverless deployment scenarios aren't possible, such as serving the app from a Content Delivery Network (CDN).