瀏覽器中的 .Net Core —— Blazor WebAssembly 初體驗
前言
在兩年多以前就聽聞 Blazor 框架，是 .Net 之父的業餘實驗性專案，其目的是探索 .Net 與 WebAssembly 的相容性和應用前景。現在這個專案已經正式成為 Asp.Net Core 框架的一部分，公開了預覽版，官方教程也基本寫好上線了。就著這個機會，順便體驗一下這個框架用起來如何。
之前在網上搜索 Blazor 的相關資訊的時候發現吵得很厲害。前端開發者大多覺得有 Vue 之類的前端 MVVM 框架已經夠用，沒有 C# 插足的餘地。甚至很多 C# 開發者也不知道這個框架的基本工作原理，覺得是把 C# 翻譯成 js，翻譯之後就變成了類似 Vue 的東西。還有人覺得這是下一個 Flash 或者 Silverlight。毛主席曾經說過：沒有調查就沒有發言權。對於說這種話的人，我只想說，少刷幾分鐘抖音快手隨便搜下百度都能搞清楚怎麼回事，作為 C# 開發者，這都理解不了我是真不知道是怎麼學的 C#，難道真是傳說中的拖控制元件一把梭，然後就沒然後了？
簡單說明下 Blazor WebAssembly 的工作原理。就是在 WebAssembly 框架的基礎上，實現了一個 .Net Core Runtime，用一個啟動 js 下載相關 dll、初始化 .Net 虛擬機器、啟動虛擬機器執行入口函式，接下來就和一個正常 .Net 程式一樣，該怎麼執行怎麼執行。用 Java 的說法就是在瀏覽器中執行的 jvm。從此，.Net 跨平臺領先 Java 一步，除了 Windows、Linux、MacOS之外，還要加上瀏覽器。悄悄說一下，瀏覽器上的執行時實現了 netstandard 2.1，待遇比傳統的 .Net Framework 還好。要說缺點就是除錯很麻煩，因為整個執行過程和伺服器無關，在 VS 下斷點也沒用，不知道是預覽版沒做好還是什麼原因，順便導致出問題很難跟蹤。還有改了程式碼要重新編譯專案，不能像 MVC 那樣改了 cshtml 重新整理下瀏覽器就生效。每次重啟除錯太耐等了。
正文
目前 Blazor WebAssembly 還不是預設專案模板的一部分，需要自行下載模板才能在 VS 2019 的專案模板裡找到，需要的可以移步官方教程。不知道有多少園友知道我有個專門收集各種各種我覺得有趣的示例程式碼的專案，當然也有很多程式碼是我自己寫的。我就冒出了一個想法，如何把這個專案也整合到我的現有專案中。畢竟建立獨立的專案和在現有專案中融合新東西完全是兩種感覺，很多元件一旦融合就會各種衝突打架，需要深入瞭解他們才能知道衝突有沒有辦法解決，要如何解決。
經過幾天的研究，我成功把 Blazor WebAssembly 專案融合進了我的主專案。同時進行了一些改造。主要方法還是先新建一個模板專案，然後對比程式碼差異，融合程式碼，補充 nuget 包。接下來簡要說明下在現有 Asp.Net Core 專案中增加 Blazor WebAssembly 專案的主要步驟。在我的專案中，/blazor 是 Blazor 根目錄，各種修改都配合這個設定，各位請根據自己的情況修改。
客戶端
1、新建一個包含 Asp.Net Core 宿主伺服器的 Blazor WebAssembly 專案。純 Blazor WebAssembly 專案釋出後可以放到靜態檔案伺服器，宿主伺服器也只是當檔案伺服器用。把客戶端專案複製到主專案解決方案中，在 VS 中新增現有專案。如果修改過專案名稱和名稱空間，請重啟 VS，不然可能報錯。
2、複製共享專案到主專案的解決方案，修復專案引用。
3、修改 wwwroot/index.html，修改 <head> 標籤中的 <base href="/" /> 為 <base href="/blazor" />。
4、在 wwwroot 資料夾新建資料夾 blazor，把 wwwroot 下的其他檔案和資料夾放進 wwwroot/blazor 資料夾，避免和主專案路徑衝突，同樣地，主專案也不能再用 /blazor/xxx 了。
服務端
1、安裝 nuget 包 Microsoft.AspNetCore.Blazor.Server，要勾上包括預發行版，不然搜不到。
2、在主專案中引用客戶端專案和共享專案。
3、在 Startup.ConfigureServices 中增加程式碼：
1 services.AddResponseCompression(opts =>
2 {
3 opts.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
4 new[] { "application/octet-stream" });
5 });
4、在 Startup.Configure 中增加 app.UseBlazorDebugging(); 如果只想在開發環境使用，自行增加 if 判斷。一般跟 app.UseDeveloperExceptionPage(); 放在一起。
5、在 Startup.Configure 中註冊 Blazor 檔案，注意型別引數，是客戶端專案的 Program 類：
app.UseClientSideBlazorFiles<BlazorApp.Client.Program>();
6、在 Startup.Configure 中檢查是否有並補充 app.UseStaticFiles();
7、在 Startup.Configure 中註冊路由終結點，注意 "/blazor/{**subPath}" 這一段，表示把 blazor 對映到 /blazor/xxx 去。{**subPath} 這一段是路由終結點引數捕獲語法，裡面的 subPath 可以亂寫，但不能空著不填，不然啟動不了。因為 Blazor WebAssembly 啟動之後路由都是前端完成的，跟伺服器沒有任何關係，所以可以亂填。只是要滿足系統的語法要求好讓伺服器能正常啟動。
1 app.UseEndpoints(endpoints =>
2 {
3 //以前的 mvc、api 等等各種註冊。
4
5 //對映 Blazor 客戶端終結點
6 endpoints.MapFallbackToClientSideBlazor<BlazorApp.Client.Program>("/blazor/{**subPath}", "index.html");
7 });
至此，融合工作完成，可以正常啟動專案並訪問 /blazor 體驗效果了。
效果預覽
在兩個瀏覽器（Chrome、Edge by Chromium）分別登入不同賬號，分別使用 Blazor WebAssembly SignalR .Net Core Client 和 SignalR Javascript Client 連線 SignalR 服務，手機（Edge Android）再登入另一個賬號使用 Blazor WebAssembly SignalR .Net Core Client 連線 SignalR 服務（域名是花生殼域名做 DDNS）。實現跨平臺跨終端實時聊天。執行在 Release 釋出模式。
結語
總體來說，Blazor 的體驗還是很不錯的，整體風格和 Asp.Net Core 幾乎一摸一樣，我看見的一瞬間就感覺非常親切。依賴注入系統也可以正常使用，只是區別是 Scope 生命週期的實際效果和單例是一樣的，因為整個應用就只有一個 Scope，但是 Blazor Server Side 就有區別了，每個 SignalR 連線繫結一個 Scope，掉線重連成功也會恢復到原先的 Scope ，一直連不上太久就不行了，整個伺服器程序包含一個單例。所以在註冊的時候儘量用 Scope，避免單例成習慣，緩不過來。
Razor 語法也是個神一樣的設計，最初是作為 MVC3 的檢視引擎推出，在 MVC4 成為預設引擎。好像 MVC5 取消了 aspx 檢視引擎支援，.Net Core 徹底取消了和 aspx 有關的一切東西。現在，Razor 又成為了一個前端渲染框架，真是老樹發新芽，又是一春。在 html 模板渲染上，我用下來就是 Razor 的 @ 和 Vue 的雙花括號語法特別順手，aspx 那種尖括號語法實在看的頭昏腦脹。本來 html 就各種尖括號，還要再來一堆尖括號，VS 高亮都看得頭疼，更別說一般文字編輯器打開了，根本看不懂，到底誰和誰是一對？Razor 就特別爽，程式碼和標記自動識別切換，區域性程式碼塊，區域性變數，比起 Vue 是有過之而無不及（Vue 的變數作用域師從 js，是真的暈）。
根據目前使用的情況來看，只要不包含涉及系統底層呼叫的庫都可以正常使用，比如和程序、執行緒、硬體驅動相關、本機 dll 互操作這種。
我在模板專案中，增加了 SignalR 客戶端使用示例。也是根據官方教程修改，而且使用的客戶端庫就是普通 .Net 客戶端庫，和控制檯、桌面程式用是同一套 dll。微軟果然神，到底是怎麼把網路相關的 API 底層實現神不知鬼不覺地的換掉的。預設注入的 HttpClient 也是 System.Net.Http 名稱空間的。
由於網路通訊底層實際上是依賴瀏覽器，所以瀏覽器會自動把 HttpClient 的請求嫁接到瀏覽器上，相關的 Headers、Cookies 自然也會自動攜帶上。所以如果 Blazor 應用和普通網頁在同一個域，這些東西實際上會共享。我的身份認證相關功能就是利用這個特點偷懶實現的。如果不在同一個域，最簡單實用的方法就是用 IdentityServer4 作為認證服務，客戶端引用 nuget 包 IdentityModel，這個包會給 HttpClient 增加一堆用來和 OpenId Connect、OAuth2.0 協議互動的擴充套件方法，當作兩個程式用開放協議配合工作來寫就行。用 IdentityModel 擴充套件獲取 Access Token，請求的時候把 Token 加進 HttpClient 的 Headers，當然也可以用 IdentityModel 的擴充套件來注入，更方便。
對於 SPA 應用來說，狀態管理一定是無法繞過的，不過在 Blazor 中，直接用依賴注入來管理狀態就可以了。如果需要重新整理頁面也不丟失狀態的話，可以考慮使用 ILocalStorage 服務來持久化狀態，或者其他持久化方案也行，反正支援 js 互操作，先隨便封裝一個應急，等 C# 的原生元件出來了再看怎麼辦。
與伺服器的互動除了常規的 Web Api，還有內部預覽階段的 gRPC-Web，等這東西搞定了，Blazor 極限使用一切二進位制資料，那效率不知道能提升多少。Asp.Net Core 3.0 全面支援 HTTP2，Chrome 好像從 70 往後也都支援 HTTP2，gRPC-Web 原生使用 HTTP2 肯定比現在包一層相容層支援 HTTP1.1 來的好。可以說在瀏覽器的限制下，能做的應該都差不多。不知道以後瀏覽器會不會開放執行緒介面讓 WebAssembly 使用核心執行緒執行計算密集型任務（好像會更方便黑客把瀏覽器當礦機啊，開放的問題也是多的不行，感覺瀏覽器就是個黑暗森林，網站伺服器要防使用者搞破壞，使用者也要防網站用指令碼搞破壞，這個猜疑鏈也導致瀏覽器各種限制，難啊）。
作為一個雜食性開發者，對於 Blazor 與 Vue 的爭論這種東西我是無所謂的，只要在我的知識範圍內在我能接受的開發複雜度內解決問題，其他的都是浮雲。就像鄧爺爺說的：實踐是檢驗真理的唯一標準；管他黑貓白貓，抓到耗子就是好貓；這才是我的信條，徹底的實用主義。
啊，C# 這種強型別安全語言進入前端領域有點激動，不注意就說了一大通。被 js 那詭異的物件型別，動態作用域坑的實在是不行，敲鍵盤的時候心虛不知道會不會莫名其妙突然就出問題，實在是對心臟不好。還是喜歡 C#，什麼東西都清晰明瞭，不埋暗坑，外加 DLR 和 dynamic，真是進可攻、退可守。js 完全沒有退路，實在是傷不起。
在最後釋出以後才發現 Blazor 聊天進不去，除錯正常，試了N多辦法都沒搞定，最後刪除釋出資料夾中的所有 dll，關閉 VS，刪除 obj、bin 資料夾，重新發布才正常。真是坑爹。
轉載請完整保留以下內容並在顯眼位置標註，未經授權刪除以下內容進行轉載盜用的，保留追究法律責任的權利！
本文地址：https://www.cnblogs.com/coredx/p/12342936.html
完整原始碼：Github
裡面有各種小東西，這只是其中之一，不嫌棄的話可以Star一下。