淺談Blazor開發的那些事

在這篇文章中，我們將解決一些常見的Blazor問題。具體來說就是"什麼是Blazor"，但更重要的是"為什麼要用Blazor"。既然我們已經有了Angular、React、Vue或其他一些JavaScript框架，為什麼還要關注Blazor 以及為什麼要選擇Blazor? WebAssembly又是關於什麼的?我們將介紹微軟的web應用程式開發框架的歷史，以及我們對其光明前景的展望。

什麼是 Blazor

Blazor有幾個常見的定義，第一個非常簡單:

Blazor是一個用.NET構建互動式客戶端web UI的框架。
-微軟文件:Blazor

正如官方文件所述，它首先是一個"框架"——它被用來構建客戶端web UI。但它與其他用於構建web UI的客戶端框架有何不同?是什麼讓它如此特別? 我希望你會問自己：".NET 有什麼不同嗎？"

這是另一個定義:

Blazor是一個免費和開源的web框架，開發者可以使用c#和HTML建立web應用程式。"
——維基百科:Blazor

哦，它是免費的——這很好。 但公平地說，還有很多其他免費框架可用於構建客戶端 Web UI。 我為什麼要關心 Blazor？

為什麼是Blazor？

從歷史上看，微軟之前所有的web UI框架都是基於完全不同的架構，並在伺服器端呈現。Blazor著手將c#開發引入web客戶端，這隻有在WebAssembly出現時才可能實現。

WebAssembly(縮寫為Wasm)是一種用於基於堆疊的虛擬機器的二進位制指令格式。Wasm被設計為程式語言的可移植編譯目標，使客戶端和伺服器應用程式能夠在web上部署。"
——webassembly.org

哇，聽起來很拗口!讓我們來分析一下:

在這種情況下，"二進位制指令格式"意味著它是位元組程式碼，從非javascript程式語言中提取抽象語法樹(AST)並將其轉換為二進位制。

Wasm位於"基於堆疊的虛擬機器"之上——這標識了基於"推送"⬇ 和"彈出"⬆ 的核心功能。指令被推送，評估被彈出。雖然這是一種過度簡化，但概念仍然存在，實現細節並不那麼重要。單執行緒、應用記憶體約束等都有一些限制，但是Blazor管理與Wasm的互操作時沒有強調這些限制。

請注意Wasm是一個"可移植編譯目標"，這一點非常重要。這意味著可以使用C、C++、Rust、C#和其他非傳統的Web程式語言，並以Wasm為目標進行編譯。這就產生了Wasm二進位制檔案，它基於開放標準，但來自JavaScript以外的程式語言。

簡言之，Blazor可與JavaScript互操作，甚至有不同的託管模型——伺服器端和Wasm的客戶端。稍後會詳細介紹……

什麼是 JavaScript?

Wasm是JavaScript的終結嗎，這意味著什麼?答案是否定的。JavaScript不會消失——Wasm應該被認為是JavaScript的補充。

預計JavaScript和WebAssembly將在許多配置中一起使用。
——webassembly.org:常見問題解答

類比

感謝 Wasm，網路瀏覽器的一些侷限性得到改善，這也是為什麼我相信：

"有了 WebAssembly，網路瀏覽器更像是應用程式商店——終端使用者體驗更接近原生效能。"

——大衛·鬆

似乎有無數特定於Wasm的新案例無法單獨使用JavaScript實現。很容易想象應用程式通過web交付到您的瀏覽器，由Wasm提供更復雜和資源密集型的案例。這就是為什麼我認為這是web應用平臺可能實現的正規化轉變。

採用

Wasm在所有主流瀏覽器中都得到了支援，並且覆蓋了幾乎93%的所有使用者——我可以使用"WebAssembly"嗎?這與Silverlight所依賴的基於外掛的方法不同。這是web的未來，您將繼續看到開發人員使用這種技術構建應用程式。

安全可靠

Wasm和JavaScript一樣安全。

WebAssembly描述了一個記憶體安全的、沙箱執行環境，它甚至可以在現有的JavaScript虛擬機器中實現。當嵌入到web中時，WebAssembly將強制瀏覽器的同源和許可權安全策略。"
——webassembly.org

換句話說，Wasm被限制在與JavaScript相同的安全沙箱中。

Web應用平臺

通過現代 Web 應用程式開發，您希望您的應用程式在桌面和移動瀏覽器上都能響應。現代 Web 應用程式比它們的前輩更加複雜和豐富，具有一些預期功能，包括實時 Web 功能、漸進式 Web 應用程式 (PWA) 功能和精心編排的使用者互動。 .NET 開發人員第一次可以使用他們現有的 C# 技能在 Web 上構建各種應用程式。在我看來，這有助於模糊後端和前端開發人員之間的界限——但更廣泛地通過web擴充套件應用程式開發。我相信在客戶端和伺服器上使用相同的程式語言的理念會促進使用者更快的採用，特別是 Node.js。

熟悉

你也許能夠很容易接受可以使用現有的C#技能進行開發，但也容易忽略這個事實：HTML、CSS和JavaScript仍然存在並可用。通過這些，您可以繼續使用您的HTML和CSS技能、您最喜歡的CSS庫，並且可以輕鬆地使用現有的JavaScript包。畢竟，您仍然在構建web應用程式!

簡史

早在 1996 年，Active Server Pages (ASP)就為 Microsoft 的動態網頁提供了第一個伺服器端指令碼語言和引擎。隨著 .NET Framework 的發展，ASP.NET 誕生了，隨之而來的是 Web Forms。 Web Forms 曾經（現在仍然）被許多喜歡 .NET 功能的人使用，它允許在伺服器端呈現 HTML。

一段時間後，ASP.NET 模型檢視控制器 (MVC) 被引入，它使 Web 窗體看起來很遲鈍。 MVC 使 ASP.NET 開發人員開始不得不瞭解網路的三大支柱： HTML、CSS 和 JavaScript。在MVC 中，有一個簡單的接近Web 標準的一致性。 MVC 還新增了一個不同的程式設計模型，它基於控制器和檢視。這有助於解決來自開發人員社群的一些阻力，開發人員注意到他們與 Web Forms 的開發互動不是無狀態的——來自與HTTP 的性質相矛盾的框架的錯覺。

ASP.NET Web API 越來越受歡迎，開發人員接受了 .NET 的強大功能。 Web API 開始被接受為構建基於 .NET 的 HTTP 服務的標準。

最終，利用 MVC 的 Razor 檢視引擎——Razor Pages 登上了舞臺。 ASP.NET Core 的創新使這一切成為可能。

ASP.NET Core 是一個跨平臺、高效能、開源的框架，用於構建支援雲的現代網際網路連線應用程式。
— Microsoft 文件：ASP.NET Core 簡介

ASP.NET Core 為您在現代開發中期望的所有基礎提供"一流公民身份"，例如（但不限於）依賴注入、強型別配置、日誌記錄、全球化和本地化、身份驗證和託管。

Razor Pages 將控制器和檢視融合在一起，使其在邏輯上更具凝聚力，更傾向於真正的元件，並構建在 Web API 基礎架構上。

在 Razor Pages 之後是 Blazor。"Blazor"這個名字是文字遊戲，結合了 B rowser和 R azor，因為開發人員擅長命名事物 – 沒錯吧？ 這就是我們今天所處的位置，在一個擁有 Blazor 及其所有功能的世界中。 針對.NET 的首創，這是一個單頁應用程式框架。

單頁應用程式(SPA)

Blazor 是 Microsoft 唯一基於 .NET 的 SPA 框架。有許多流行的 SPA 框架，包括：

• Angular
• React
• Vue
• Svelte

主要區別在於這些都是基於 JavaScript，而不是 Wasm。

有時，使用 Blazor 構建應用程式的開發人員會混淆兩種託管模型的差異。有人誤解 Blazor 伺服器（伺服器端）不是 SPA。伺服器端的本質感覺更像是以前的非 SPA .NET Web 應用程式框架。但讓我們看看 SPA 的定義：

“單頁應用程式 (SPA) 是一種 Web 應用程式或網站，它通過使用來自 Web 伺服器的新資料動態重寫當前網頁來與使用者互動，而不是 Web 瀏覽器載入整個新頁面的預設方法”
— 維基百科：單頁應用程式

無論託管模型如何，Blazor 都滿足此定義。使用 Blazor 伺服器，伺服器公開具有特定 Blazor 協議的 SignalR集線器，該協議負責實時傳達客戶端應用程式中文件物件模型 (DOM) 的更新。當 DOM 中存在差異（或增量）時，更改會立即反映出來。

在 Blazor WebAssembly 中，當客戶端請求應用程式時，它會作為一些 HTML、CSS 和 JavaScript 提供——就像所有其他 Web 應用程式一樣。 blazor.webassembly.js 檔案引導應用程式並開始載入 .NET 二進位制檔案，可以在瀏覽器的"網路"選項卡中通過網路檢視這些檔案。

開源

它是開源的，作為 ASP.NET Core GitHub 儲存庫的一部分。

Github dotnet / aspnetcore：

ASP.NET Core 是一個跨平臺的 .NET 框架，用於在 Windows、Mac 或 Linux 上構建基於雲的現代 Web 應用程式。

我是開源軟體開發的大力支持者。對我來說，能夠公開地看到一個功能是如何構建、設計和實現的，這改變了遊戲規則。釋出問題、提出特性、與開發團隊和其他人協作以及建立拉取請求的能力使軟體社群為中心。毫無疑問，這最終會產生更好的產品！

程式碼重用

SPA 開發人員多年來一直在打一場失敗的戰鬥，在這種情況下，Web API 端點定義了特定形狀的有效負載——開發人員必須瞭解每個端點的形狀，最好對映到客戶端上的模型。這是一個非常乏味的過程，並且容易出錯。 Blazor 可以通過與 Blazor 客戶端應用程式共享來自 .NET Web API 的模型來緩解這種擔憂。

整個 .NET 庫都可以在伺服器端和客戶端場景中共享和使用。利用現有的邏輯、功能和能力讓開發人員可以專注於更多的創新，因為他們不需要重新定義基礎工具。

工具

開發團隊的生產力始終是所有型別的應用程式開發的主要關注點。現有的開發人員工具是成功的關鍵，如果您的團隊摸索或努力完成常見的程式設計任務——整個專案可能會失敗。使用Blazor開發，您可以使用經過驗證好的開發人員工具，如:

• Visual Studio
• Visual Studio for Mac
• Visual Studio程式碼

此外， .NET CLI已經成為一個生產力強大的工具，具有新的(模板)、構建、恢復、釋出、執行、測試、打包和遷移命令(僅舉幾個例子)——使用它會大大提升您專案成功的可能性。

所有這些都是用當今世界上最強大、最現代的程式語言構建的——我的觀點那就是C#。

.NET APIs

作為一個擁有十多年真實web應用程式開發經驗的開發人員，我可以有把握地說，我曾經多次可靠地使用.NET進行企業生產應用程式的開發。.NET本身的API surface area就很大， 並且作為一個由NuGet提供的第三方包組成的生態系統，難道不值得喜歡嗎?

** 為什麼這很重要? **

我最近見證了一個.NET API的開發過程，從它的開始到它的成果——我觀察到這個過程非常的成熟和穩定。

請記住，為了讓公眾看到，這是完全公開的。最開始在早期的討論期間，一個想法誕生了，然後以一個官方提案的形式在GitHub上提出。這個問題包含了您對提案的所有期望，問題陳述、用例、示例語法、建議的API surface area、示例用法，甚至還有來自原始討論和想法的評論的連結。

這個提案會經過長時間的討論，建議、推理和談判。最終由參加公開API設計評審會議的人最終確定一個草案。官方的.NET API設計評審會議遵循每週會議安排。稽核過程中，將捕獲註釋，應用GitHub標籤，最終獲得批准——這樣，有問題的.NET API就被編碼為一個程式碼片段。

從這裡開始，該問題就成為了旨在滿足提議的pull請求的參考點。開發人員處理問題，實現API，編寫單元測試，並建立pull request (PR)。PR要經過審查，當它被合併時，API必須被記錄、溝通、捕獲/報告、推廣、共享、分析等等。

所有這些，像這樣一個.NET API，有成千上萬的.NET API存在。在所有.NET貢獻者的支援下，您將得到很好的幫助。有關更多資訊，請參閱官方API審查流程。

我向一個對.NET API非常重視的朋友詢問了一些關於這個主題的恰當詞語:

“.NET平臺以擁有一組非常有用的api而自豪，無論你在構建哪種應用程式，這些api都能讓你的使用非常高效。有了Wasm，當您使用Blazor WebAssembly構建基於瀏覽器的應用程式時，也可以使用這種功能。”
——Immo Landwerth

支援

對於所有.NET產品，都有各種各樣的支援策略。對於開發團隊來說，理解發布的生命週期及其相應的支援策略通常是一個重要的考慮因素。在大多數情況下，建議構建面向.NET長期支援(Long Term Support, LTS)版本的生產就緒應用程式。然而，一些公司和開發團隊選擇跟蹤當前(甚至預覽)版本——他們傾向於更積極地遷移。要了解更多資訊，請參閱官方的.NET站點，瞭解支援細節:

• .NET支援政策
• 什麼是覆蓋

開發者社群

我向一些Blazor開發者社群的朋友詢問了他們的想法，並在被問及"為什麼是Blazor?"的時候，他們回答：

Blazor的元件模型使構建應用程式成為一種樂趣。它很簡單，但是當你需要它的時候，它又能提供很多定製服務。
— 克里斯·桑蒂@chrisainty

我同意克里斯的看法。開發簡單且可定製的應用程式有很多樂趣。

.NET的生產力高效。我可以使用我現有的技能、工作流程、工具和以前編寫的庫。這裡沒有npm或webpack，但是，我有.NET堆疊和它的生態系統，這讓我超級高效。
——Ed charbenau @ edcharbenau

我完全同意埃德的觀點。生產力是一個關鍵的驅動因素——而且不需要編寫大量的JavaScript當然可以減輕web開發的痛苦。

Blazor開發者社群正在蓬勃發展:

令人敬畏的Blazor: Blazor資源的集合

Awesome Blazor瀏覽器:搜尋Awesome Blazor資源

Blazor紀念日:2021

發展前景

除了令人驚歎的Blazor開發者社群、開發者工具、開源生態系統和受人尊敬的行業領袖的強烈意見外，還有來自主要元件供應商的整個UI元件發展，他們正在積極構建Blazor元件(按字母順序排列):

• DevExpress
• GrapeCity
• Infragistics
• Radzen
• Smart HTML Elements
• Syncfusion
• Telerik

客戶故事

每當微軟的客戶興奮地分享他們的故事時，他們也在為自己說話——這裡有兩個Blazor的成功故事:

• 通用航空
• 郵資

程式碼

要快速建立一個Blazor WebAssembly專案，請使用dotnet new blazorwasm .NET CLI命令。

在前面的命令中，我們指定了專案的名稱(-n)，並且我們不希望進行恢復。如果你要開啟Pages/Counter。在razor檔案中，你會看到一些類似於下面的razor程式碼:

@page "/counter"

<h1>Counter</h1>

<p>Current count: @_currentCount</p>

<button class="btn btn-primary"
        @onclick="IncrementCount">
     Click me
</button>

@code {
    private int _currentCount = 0;

    private void IncrementCount() =>
        ++ _currentCount;
}

這是一個簡單的計數器頁面。它被認為是一個頁面而不是一個元件，因為它的@page指令指定了"/counter"的頁面路徑。因為它是基於Razor檢視引擎的，所以它就像一個模板——在這裡你可以引用HTML中的c#程式碼變數。這也演示了@code{…}指令，它允許你將c#功能直接嵌入到模板檔案中。_currentCount變數是私有的，作用域是頁面，並從IncrementCount方法遞增。該方法在單擊按鈕時呼叫，並通過@onclick事件繫結。隨著_currentCount值的增加，更改會立即反映到繫結的位置。在本例中，它們作為"Current count"顯示在元素中。

計數器頁面只是一個小例子展示了可能性，作為一個網頁開發人員，在這裡有更多的驚喜等待著您。 我希望.NET會是您下一個web應用程式開發專案中會考慮的工具。

總結

作為開發人員，有許多工具可供您選擇。對於所有開發人員的選擇，當決定是否使用某一種框架時，應該是由整個團隊所決定。Blazor是另一個選擇，但並不適用於所有用例——知道何時使用它與知道如何使用它一樣重要。在這篇文章中，我們討論了"什麼"和"為什麼"。"如何"這個詞已經有很多報導了。

請考慮其他資源:

• 在Microsoft Learn上用Blazor構建一個web應用程式
• 介紹了ASP.NET Core Blazor
• Blazor託管模型
• Blazor JavaScript互動操作
• Blazor WebAssembly效能

有任何技術問題，請在 Microsoft Q&A上提問。