轉載技術社區中一位朋友最新的文章，介紹自己為公司的 WebForm 遺留系統使用 Blazor 重寫前端 UI 的經歷。

前言

啊，又好久沒寫文章了，這一年一直在接觸新的領域，擴展了一下技術面，學了很多新東西。

前陣子發現公司內部有個后臺管理系統，因為歷史悠久，還是Webform做的，不管是UI風格還是代碼設計，都已經落后于時代。因為項目陳舊，所以后續新增或修改功能的人，也往往抱著多一事不如少一事的心態添加各種“補丁”。久而久之，后來的人不再樂意維護這樣的系統；而落后于時代的UI風格，也讓使用者覺得整個系統看上去很“Low”；對接觸過市面上第三方后臺系統的公司管理者來說，自家的后臺系統更顯得老氣橫秋，需要一次“新生”。

當大家對一個系統都產生不滿的時候，就可以考慮重構或者重寫它了。這一切的開始，自然是考慮技術選型。

最初我考慮使用比較常見的前后端分離模式，后端自然是使用ASP.NET?Core + EF Core，前端使用公司內部已經比較成熟的基于Ant-Design-Vue封裝的組件模板。但是這樣的缺陷也很明顯，那就是遇到迭代需求，要么需要前端的人員參與，要么后端人員起碼要熟練運用JavaScript和模板。而后臺管理系統的功能迭代，往往來得比較突兀：一方面需求方是內部的使用者，使用頻率不固定；另一方面每一次的迭代其實對內來說并沒有產生運營價值。因此對后臺管理系統的要求是，盡可能單人就能較快的完成前后端工作。

那么有讀者可能會嘲笑了：干嘛非要前后端分離？后臺直接ASP .NET Core MVC后端渲染好了嘛！當然可以。不過一方面是考慮到MVC組件化開發，我們沒有什么實踐經驗；另一方面是后臺系統的頁面既可能出現非常多的元素，又要簡潔易用，前后端分離可以將后端變得非常輕量（基本只需CRUD），而由前端分擔偏重的邏輯。如果回到后端渲染的模式，那么很可能過了幾年之后，又變成了今天Webform的情況：例如一個復雜頁面，在后端Page對象里寫了一大堆的變量來維護頁面控件的狀態……

現在問題變成了：有沒有一個Web UI框架，可以很好地和ASP.NET?Core后端搭配呢？我的目光自然放到了年輕的Blazor身上。

Blazor發行才兩年，最初我并沒有重視它。當然，最大的原因是彼時我未有與之關聯的實際需求，另外也包括——

• 最早Blazor只發行了Blazor Server，Client Side姍姍來遲以至于我誤認為尚處于“全民測試階段”

• 鑒于Webform、MVC，以及曾經的Silverlight，我對Blazor在前端領域的發展缺乏信心

• Blazor WebAssembly是基于WebAssembly的UI框架先行者，最先吃螃蟹的人，往往也會因為過于超前的理念最終走向沉寂

• Blazor還太年輕，生態沉淀遠不如前端三大框架

但現在是2021年了，當我真正嘗試了解它時，它帶給了我非常大的——驚喜。同時，Blazor開源社區也給了我很大的幫助。最大的助力，來自于我前同事?

@JamesYeung

?的開源項目：Ant Design Blazor 。在我花了兩個星期的時間，寫出舊系統部分頁面的demo之后，我深感以前自己對Blazor太缺乏了解和信任。我覺得有必要將我曾經的誤解，以及現在的心得體會，寫入“DotNet應用”系列文章，以供讀者參考和交流。

什么是Blazor

官方文檔已經將Blazor應用放在了“C位”。由于官方文檔的介紹十分貼切，這里請容許我原封不動地搬運過來：

Blazor 是一個使用 .NET 生成交互式客戶端 Web UI 的框架：
使用 C# 代替 JavaScript 來創建信息豐富的交互式 UI。
共享使用 .NET 編寫的服務器端和客戶端應用邏輯。
將 UI 呈現為 HTML 和 CSS，以支持眾多瀏覽器，其中包括移動瀏覽器。
與新式托管平臺（如 Docker）集成。第一個就是“我”——Blazor！

簡而言之，.NET開發者可以用C#來寫單獨的前端了。

那么Blazor是一蹴而就的嗎？顯然非也。Blazor的誕生，受益于Web Assembly和近些年.NET Core技術的發展；Blazor使用的Razor語法，則是在MVC時代就已經發布的標記語法；Blazor的組件開發思想，則早已在前端成為主流的開發模式……總而言之，Blazor既是一個基于Web Assembly、走在技術前沿的Web UI框架，也是一個借鑒和總結了以往成熟開發經驗的框架。

Blazor和前端三大框架的關系

說到Blazor，必然會有人拿它跟現有廣泛應用的前端三大JS框架（React/Vue/Angular）對比，我也闡述一下個人觀點。

首先，Blazor在框架設計上并沒有閉門造車。在使用Blazor的過程中，可以充分感受到Blazor和當前主流前端技術的聯系：

• 組件式開發的范式，推薦以組件的形式作為頁面基本的UI元素

• 在html模板中，部分C#關鍵詞充當了類似“指令”的角色。例如@if和ng-if, @for和vue-for等等

• html/css/code(JS/C#)的分離和組合。Blazor里每個頁面既可以拆分成MyPage.razor（html模板文件）,MyPage.razor.cs（C#代碼文件）和MyPage.razor.css（樣式文件）三部分，也可以將三者統一寫到MyPage.razor文件里。

• 依賴注入。有過Angular開發經驗的開發者，應該會對此深有體會。

其次，Blazor保留了C#和JS之間的互操作性。也就是說，Blazor既理所當然地利用了.NET現有的生態，也兼容更加繁榮的JS生態。這樣開放的思路，給了Blazor開源社區非常大的發展空間，比如很多早先由原生JS編寫的圖表開源項目，可以以相對較低的成本遷移到Blazor上來；又比如可以使用Blazor封裝三大框架已有的組件，或者原生組件（播放器等）。

因此，Blazor和前端三大框架之間，的確有相當一部分的功能其實可以互相取代。然而Blazor的目的，不是為了取代三大框架；從現狀來看，甚至連競爭的地位都談不上。Blazor能吸引的最主要人群，是.NET開發者，它給了開發者完全以C#作為主要語言實現全棧開發的機會。尤其是，前后端可以共享包含數據類型和邏輯模塊的C#代碼，這一優勢只有C#全棧開發者才能深切體會到。例如，對于后端出身的C#開發者，在前后端分離的環境下，以往更偏愛設計模式上與后端更相近的Angular；如今Blazor已逐漸成熟，可以“橫刀奪愛”了。

如上所說，Blazor并不能讓三大框架的絕大多數JS開發者產生興趣，更無法與當下繁榮的JS生態競爭。另外，在IE及其他一些老舊版本的瀏覽器仍未被完全淘汰的當下，為了保證頁面的普適和兼容，Blazor自然不會被大部分人看重。但作為基于Web Assembly的前端框架，它依然還是特別的：wasm的普及和發展，一定會利及Blazor，使其在未來有更大的發展空間。這里舉一個即將實現的例子：由于wasm可以在非Web環境下運行，那么Blazor將來也可以用于開發運行在非Web環境下的UI程序，這在官方的計劃中已經提及——Blazor Web Assembly MAUI。

Blazor會是另一個Silverlight嗎

這可能是一部分人最關心的問題。微軟曾經發布了不少“愿景很好”的技術棧，但最終有一部分隨著時代走向了沉寂。如今稚嫩的Blazor，是否能走出一條康莊大道？還是說會成為另一個Silverlight，過些年之后就變成了歷史？

如前言所說，我恰是從這樣的疑慮走出來的。現在，我將個人的判斷寫在這里以供讀者參考：

• 在可預期的未來，Blazor將是微軟主打的Web UI框架

• Blazor完全借鑒和遵循當下前端流行的設計模式和思想，沒有閉門造車

• Blazor開源社區的活躍度在逐步提高，除了組件庫之外，還有越來越多的功能庫

• Blazor的根基在于Web Assembly，wasm將是未來瀏覽器的核心規范，它更高效更安全更開放，且更標準（無版本，特性可測試、向后兼容）

• Blazor在性能、可靠和開發效率上，是一流的框架。而近期在.NET 6到來后，AOT和Hot Reload將進一步提升Blazor程序的運行性能和開發體驗

鑒于前后端分離的流行程度，以及wasm的發展空間，我個人的結論是：Blazor不會成為另一個Silverlight。相反地，它更可能成為.NET生態在前端開發領域的大本營。

為什么要用Blazor做后臺

首先要明確，這個問題主要針對的是.NET技術棧的公司或個人。

從技術選擇的角度來說，我認為前后端分離自然地隔離了邏輯和表現，對日后的維護更加友好。以前對.NET技術棧的公司來說，前后端分離需要開發者掌握C#和JS，同時數據類型和邏輯模塊經常會出現兩種語言上的重復，這些對自用的后臺來說都是不必要的成本；現在使用Blazor已經解決了這個問題。而且公司內部的后臺通常不需要兼容老舊瀏覽器，恰恰避開了wasm的業務弱項，反倒為其更好的性能表現提供了舞臺。

從設計需求的角度來說，我個人總結了后臺系統頁面的特點，基于Blazor開源組件項目，可以天然地滿足：

簡潔。頁面不過分追求華麗，以清晰的布局為重

一致。所有頁面呈現的UI風格應當一致

效率。盡可能復用組件和代碼搭建頁面，實現快速迭代

平衡。既易于使用，又盡可能防止敏感數據誤操作

及時。有較好的頁面加載速度，對等待操作有清楚及時的反饋

總而言之，我的結論就是：Blazor應當是.NET公司開發或重寫內部后臺系統的首選框架！

結語

當然，個人膚淺之見，難免會有讀者質疑。在接下來的系列文章里，我將逐步介紹Blazor組件、Ant-Design-Blazor開源組件，以及做一個demo項目的過程、心得和一些重要細節。

希望這個系列，能夠讓更多的.NET開發者豐富對Blazor的認識，降低學習Blazor的門檻；讓有類似需求的開發者們，能夠打消疑慮，增加應用Blazor的信心，融入Blazor的開源社區和發展事業！祝事業順利，讓我們下一篇文章再會！

總結

以上是生活随笔為你收集整理的使用Blazor开发内部后台（一）：认识Blazor的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。