Blazor server VS Blazor WebAssembly


Blazor WebAssembly

主要的 Blazor 托管模型在 WebAssembly 上的瀏覽器中運行客戶端。 將 Blazor 應用、其依賴項以及 .NET 運行時下載到瀏覽器。 應用將在瀏覽器線程中直接執行。 UI 更新和事件處理在同一進程中進行。 應用資產作為靜態文件部署到可為客戶端提供靜態內容的 Web 服務器或服務中。

Blazor WebAssembly:Blazor 應用在瀏覽器內部的 UI 線程上運行。

如果創建了 Blazor WebAssembly 應用進行部署,但沒有后端 ASP.NET Core 應用來為其文件提供服務,那么該應用被稱為獨立 Blazor WebAssembly 應用。 如果創建了應用進行部署,但沒有后端應用來為其文件提供服務,那么該應用被稱為托管的 Blazor WebAssembly 應用。 托管的 Blazor WebAssembly Client 應用通常使用 Web API 調用或 SignalR(結合使用 ASP.NET Core SignalR 和 Blazor)通過網絡與后端 Server 應用交互。

blazor.webassembly.js 腳本由框架和句柄提供:

  • 下載 .NET 運行時、應用和應用依賴項。
  • 初始化運行應用的運行時。

Blazor WebAssembly 托管模型具有以下優點:

  • 沒有 .NET 服務器端依賴項。 應用下載到客戶端后即可正常運行。
  • 可充分利用客戶端資源和功能。
  • 工作可從服務器轉移到客戶端。
  • 無需 ASP.NET Core Web 服務器即可托管應用。 無服務器部署方案可行,例如通過內容分發網絡 (CDN) 為應用提供服務的方案。

Blazor WebAssembly 托管模型具有以下局限性:

  • 應用僅可使用瀏覽器功能。
  • 需要可用的客戶端硬件和軟件(例如 WebAssembly 支持)。
  • 下載項大小較大,應用加載耗時較長。
  • .NET 運行時和工具支持不夠完善。 例如,.NET Standard 支持和調試方面存在限制。

若要創建 Blazor WebAssembly 應用,請參閱 用於 ASP.NET Core Blazor 的工具。

Blazor 托管應用模型支持 Docker 容器。 對於 Visual Studio 中的 Docker 支持,請右鍵單擊托管的 Blazor WebAssembly 解決方案的 Server 項目,然后選擇“添加” > “Docker 支持”。

Blazor Server

使用 Blazor Server 托管模型可從 ASP.NET Core 應用中在服務器上執行應用。 UI 更新、事件處理和 JavaScript 調用是通過 SignalR 連接進行處理。

瀏覽器通過 SignalR 連接與服務器上的應用(該應用托管在 ASP.NET Core 應用內部)進行交互。

ASP.NET Core 應用會引用應用的 Startup 類以添加以下內容:

  • 服務器端服務。
  • 用於請求處理管道的應用。

在客戶端上,blazor.server.js 腳本與服務器建立 SignalR 連接。 腳本由 ASP.NET Core 共享框架中的嵌入資源提供給客戶端應用。 客戶端應用負責根據需要保持和還原應用狀態。

Blazor Server 托管模型具有以下優點:

  • 下載項大小明顯小於 Blazor WebAssembly 應用,且應用加載速度快得多。
  • 應用可充分利用服務器功能,包括使用任何與 .NET Core 兼容的 API。
  • 服務器上的 .NET Core 用於運行應用,因此調試等現有 .NET 工具可按預期正常工作。
  • 支持瘦客戶端。 例如,Blazor Server 應用適用於不支持 WebAssembly 的瀏覽器以及資源受限的設備。
  • 應用的 .NET/C# 代碼庫(其中包括應用的組件代碼)不適用於客戶端。

 重要

Blazor Server 應用預呈現以響應第一個客戶端請求,這會在服務器上創建 UI 狀態。 客戶端嘗試創建 SignalR 連接時,“必須重新連接到同一服務器”。 使用多個后端服務器的 Blazor Server 應用應實現粘滯會話,從而建立 SignalR 連接。 有關更多信息,請參見連接到服務器一節。

Blazor Server 托管模型具有以下局限性:

  • 通常延遲較高。 每次用戶交互都涉及到網絡躍點。
  • 不支持脫機工作。 如果客戶端連接失敗,應用會停止工作。
  • 如果具有多名用戶,則應用擴縮性存在挑戰。 服務器必須管理多個客戶端連接並處理客戶端狀態。
  • 需要 ASP.NET Core 服務器為應用提供服務。 無服務器部署方案不可行,例如通過內容分發網絡 (CDN) 為應用提供服務的方案。

若要創建 Blazor Server 應用,請參閱 用於 ASP.NET Core Blazor 的工具。

Blazor Server 應用模型支持 Docker 容器。 對於 Visual Studio 中的 Docker 支持,請右鍵單擊 Visual Studio 中的項目,然后選擇“添加” > “Docker 支持” 。

與服務器呈現的 UI 進行比較

理解 Blazor Server 應用的一種方法是,了解其與使用 Razor 視圖或 Razor Pages 在 ASP.NET Core 應用中呈現 UI 的慣用模型之間的差異。 這兩種模型都使用 Razor 語言描述 HTML 內容,但兩者在標記的呈現方式上差別顯著。

呈現 Razor 頁面或視圖時,每行 Razor 代碼都以文本形式發出 HTML。 呈現后,服務器會丟棄頁面或視圖實例,包括生成的任何狀態。 出現另一個對該頁面的請求時,例如,服務器驗證失敗並顯示驗證摘要時:

  • 整個頁面將再次重新呈現為 HTML 文本。
  • 頁面會發送到客戶端。

Blazor 應用由 UI 的可重用元素組成,這些元素稱為組件。 組件包含 C# 代碼、標記和其他成分。 呈現組件時,Blazor 會生成所含組件的圖,類似於 HTML 或 XML 文檔對象模型 (DOM)。 此圖包含屬性和字段中保存的組件狀態。 Blazor 會評估組件圖,生成二進制形式的標記。 二進制格式可以:

  • 轉換為 HTML 文本(預呈現 † 期間)。
  • 用於在定期呈現期間高效更新標記。

†預呈現:請求獲取的 Razor 組件在服務器上編譯為靜態 HTML,並發送到客戶端,然后呈現給用戶。 客戶端與服務器之間建立連接后,組件的靜態預呈現元素會替換為交互式元素。 預呈現會使應用對用戶的響應更加迅速。

Blazor 中的 UI 更新由以下內容觸發:

  • 用戶交互,例如選中按鈕。
  • 應用觸發器,例如計時器。

組件組已預呈現,且已計算 UI diff(差異)。 此差異是更新客戶端上的 UI 所需的最小一組 DOM 編輯。 差異以二進制格式發送到客戶端,並由瀏覽器應用。

用戶在客戶端上退出組件之后,組件會被丟棄。 用戶與組件交互時,組件的狀態(服務、資源)必須保存在服務器的內存中。 由於服務器可能同時保存多個組件的狀態,因此必須解決內存不足的問題。 要了解如何創作 Blazor Server 應用以確保充分使用服務器內存,請參閱 ASP.NET Core Blazor Server 的威脅緩解指南。

線路

Blazor Server 應用基於 ASP.NET CoreSignalR 構建。 每個客戶端通過一個或多個稱為“線路”的 SignalR 連接與服務器通信。 線路是 Blazor 對可容忍短暫網絡中斷的 SignalR 連接的抽象。 Blazor 客戶端發現 SignalR 連接已斷開時,它會嘗試使用新的 SignalR 連接來重新連接到服務器。

連接到 Blazor Server 應用的每個瀏覽器屏幕(瀏覽器標簽頁或 iframe)均使用 SignalR 連接。 與典型服務器呈現應用相比,這是另一個關鍵差異。 在服務器呈現應用的多個瀏覽器屏幕中打開同一應用通常不需要服務器上的其他資源。 在 Blazor Server 應用中,若服務器要管理瀏覽器屏幕,則每個瀏覽器屏幕均需要獨立線路和組件狀態的獨立實例。

Blazor 將關閉瀏覽器標簽頁或訪問外部 URL 視為正常終止。 如果正常終止,則會立即釋放線路和關聯的資源。 例如,由於網絡中斷,客戶端也可能異常地斷開連接。 Blazor Server 會將斷開連接的路線存儲一段時間(可配置),以便客戶端重新連接。

Blazor Server 允許代碼定義線路處理程序,后者允許在用戶線路的狀態發生更改時運行代碼。 有關詳細信息,請參閱 ASP.NET Core Blazor SignalR 指南。

UI 延遲

UI 延遲是指從啟動操作到 UI 更新所需的時間。 要使應用對用戶進行響應,需要 UI 延遲值較小。 在 Blazor Server 應用中,每個操作都會發送到服務器並進行處理,然后發回 UI 差異。 因此,UI 延遲是網絡延遲和處理操作時的服務器延遲的總和。

如果是僅用於專用公司網絡的商業應用程序,用戶通常不易感受到因網絡延遲而導致的延遲。 如果是通過 Internet 部署的應用,用戶可能會更容易感受到延遲,用戶分布廣泛時感受尤為明顯。

內存使用也會導致應用延遲。 內存使用率增大會導致垃圾收集頻繁或內存分頁到磁盤,兩者均會降低應用性能,進而增大 UI 延遲。

Blazor Server 應用應降低網絡延遲和內存使用率,從而優化以最大限度地降低 UI 延遲。 有關測量網絡延遲的方法,請參閱 托管和部署 ASP.NET Core Blazor Server。 有關 SignalR 和 Blazor 的詳細信息,請參閱以下內容:

  • 托管和部署 ASP.NET Core Blazor Server
  • ASP.NET Core Blazor Server 的威脅緩解指南

連接到服務器

Blazor Server 應用需要與服務器建立有效的 SignalR 連接。 如果連接丟失,應用會嘗試重新連接到服務器。 只要客戶端的狀態仍在服務器的內存中,客戶端會話即可恢復,且不會失去狀態。

Blazor Server 應用預呈現以響應第一個客戶端請求,這會在服務器上創建 UI 狀態。 客戶端嘗試創建 SignalR 連接時,必須重新連接到同一服務器。 使用多個后端服務器的 Blazor Server 應用應實現粘滯會話,從而建立 SignalR 連接。

我們建議將 Azure SignalR 服務用於 Blazor Server 應用。 該服務允許將 Blazor Server 應用擴展到大量並發 SignalR 連接。 可將服務的 ServerStickyMode 選項或配置值設置為 Required,從而為 Azure SignalR 服務啟用粘滯會話。 有關詳細信息,請參閱 托管和部署 ASP.NET Core Blazor Server。

使用 IIS 時,粘滯會話通過應用程序請求路由啟用。 有關詳細信息,請參閱使用應用程序請求路由實現 HTTP 負載均衡。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM