[Asp.Net Core] 淺談Blazor Server Side

更新時(shí)間：2020年07月01日 15:16:36 作者：軒軒之家

這篇文章主要介紹了[Asp.Net Core] Blazor Server Side 的相關(guān)資料，文中示例代碼非常詳細(xì)，幫助大家更好的理解和學(xué)習(xí)，感興趣的朋友可以了解下

在2016年, 本人就開(kāi)始了一個(gè)內(nèi)部項(xiàng)目, 其特點(diǎn)就是用C#構(gòu)建DOM樹(shù), 然后把DOM同步到瀏覽器中顯示. 并且在一些小工程中使用.

3年下來(lái), 效果很不錯(cuò), 但因?yàn)槭鞘褂肅#來(lái)構(gòu)建控件樹(shù), 在沒(méi)有特定語(yǔ)法的情況下, 代碼風(fēng)格不是那么好.

典型的風(fēng)格大概是這樣的:

這個(gè)模式挺好的, 有點(diǎn)嫌棄C#代碼占比太高, HTML代碼靠字符串來(lái)完成, 在界面的設(shè)計(jì)上, 比較吃力.

在2019年秋, Asp.Net 3.0出來(lái)了, Blazor Server Side 也正式公布, 可以在VS2019中使用.

當(dāng)時(shí)我就去嘗嘗鮮, 發(fā)現(xiàn)這東西, 和我的框架很接近. 不同的是,

Blaozr Server Side 是基于 MVVM 的, 而我的框架是基于傳統(tǒng)控件樹(shù)的.

Blazor畢竟有微軟做爸爸, 在VS上的支持是直接的, 由Razor文件來(lái)負(fù)責(zé) HTML+C# 的代碼模式, 完全支持智能提示.

天呀, 這不是就是我夢(mèng)寐以求的開(kāi)發(fā)方式嗎? 于是, 在疫情期間, 我把以前的框架, 和Blazor直接整合在一起. 開(kāi)始做一些小工程做驗(yàn)證.

現(xiàn)在這個(gè)整合大部分需求與問(wèn)題都得到了解決. 還需要提供更多的控件用以提高工程的開(kāi)發(fā)速度.

先上圖, 看看 Blazor 的代碼是長(zhǎng)什么樣子的.

(Razor語(yǔ)法, 和MVC有點(diǎn)接近. 但是MVC是輸出靜態(tài)HTML的, Blazor組件是生成服務(wù)器樹(shù)狀結(jié)構(gòu)的)

與 MVC 的 Razor語(yǔ)法是接近的 , 然而最大不同時(shí) , MVC 的最終目標(biāo)是生成字符串發(fā)給瀏覽器. 而B(niǎo)lazor生成了模型之后, 依然是"活動(dòng)"的, 隨時(shí)準(zhǔn)備好響應(yīng)客戶(hù)端的事件.

對(duì)于 Blazor 架構(gòu)的一些特點(diǎn), 畫(huà)了一些圖.

首先, 我把這種模式成為 "服務(wù)器UI映射" , 后面都會(huì)陸續(xù)使用這個(gè)概念.

個(gè)人看法 , 通常的情況, 僅供參考

Blazor 因?yàn)樵诜?wù)器上把代碼運(yùn)行狀態(tài)駐留在內(nèi)存,

所以程序運(yùn)行的上下文得以保存, 而關(guān)聯(lián)的事件也會(huì)綁定到上下文中.

事件處理函數(shù)被調(diào)用時(shí), 相關(guān)的對(duì)象和數(shù)據(jù)會(huì)全部可用.

具體的細(xì)節(jié)無(wú)法說(shuō)太多, 畢竟這是新事物, 我自己也是一邊使用一邊積累心得.

我以后會(huì)陸陸續(xù)續(xù)放上各種例子, 提供給感興趣的網(wǎng)友們, 用節(jié)省時(shí)間的方式去迅速掌握Blazor的開(kāi)發(fā)流程.

最后, 放上一個(gè)對(duì)照表, 以供參考:

	服務(wù)器UI映射	C/S	B/S	B+C混合
簡(jiǎn)單概述	活在服務(wù)器投影到客戶(hù)端	活在客戶(hù)端與服務(wù)器通信	服務(wù)器生成HTML 客戶(hù)端展示與回發(fā)	服務(wù)器先生成HTML 客戶(hù)端深化界面功能
典型方案	Blazor Server Side at server hosted	平臺(tái):Windows/Android/iOS GUI框架網(wǎng)頁(yè):JS控件類(lèi)/React/Argular/Vue.. Blazor WebAssembly Blazor Server Side at client hosted	各種WEB服務(wù)器方案: ASP/ASP.NET WebForms,MVC PHP/Java/Node.js/..	各種框架混合使用
典型應(yīng)用	無(wú) , 適合: 微信公眾號(hào)應(yīng)用, 網(wǎng)站后臺(tái), 手機(jī)嵌入頁(yè)面小程序webview嵌入頁(yè)面	各種Desktop/Mobile客戶(hù)端游戲客戶(hù)端,網(wǎng)站SPA,微信小程序,	各種入門(mén)級(jí)展示型網(wǎng)站	各種復(fù)雜點(diǎn)的網(wǎng)站
讀寫(xiě)數(shù)據(jù)	直接, 方便	需通過(guò)服務(wù)器代勞	直接, 方便	混合
通信方式	已在服務(wù)器運(yùn)行	HTTP/Socket/WebSocket等等由各平臺(tái)/框架提供	HTTP GET/POST為主	混合
通信代碼	無(wú)需額外編寫(xiě)(優(yōu)點(diǎn))	基于XML/JSON/Query/Form/自定格式程序員指定具體的名稱(chēng)與值服務(wù)器與客戶(hù)端都要編寫(xiě)大量代碼(缺點(diǎn)) 關(guān)乎權(quán)限的話要保證安全性,工作量會(huì)很大	主要是Query/Form 程序員指定具體的名稱(chēng)與值只適合簡(jiǎn)單的程序	混合
服務(wù)重啟熱更新	丟失未保存的狀態(tài)(缺點(diǎn)) 對(duì)正使用的用戶(hù)造成影響	未保存狀態(tài)在客戶(hù)端保存只要重試便可	狀態(tài)在瀏覽器保存只要重試便可	狀態(tài)在瀏覽器保存只要重試便可
服務(wù)器負(fù)荷	最重,(缺點(diǎn)) 每在線用戶(hù)會(huì)占用服務(wù)器內(nèi)存只適合少量在線用戶(hù)場(chǎng)合	最少(優(yōu)點(diǎn)) 服務(wù)器基本上只處理業(yè)務(wù)邏輯每個(gè)請(qǐng)求會(huì)很快釋放,負(fù)擔(dān)很小	不多	較少
適合場(chǎng)景	資金少的企業(yè)定制應(yīng)用用戶(hù)量較少的小功能以快速開(kāi)發(fā)為目標(biāo)	通用開(kāi)發(fā)模式適合絕大部分情況	比較適合內(nèi)容展示網(wǎng)站或比較簡(jiǎn)單的業(yè)務(wù)系統(tǒng)	混合
代碼部署	純服務(wù)器,更保密	客戶(hù)端,沒(méi)那么保密(缺點(diǎn)) 通信機(jī)制可能會(huì)被濫用攻擊	服務(wù)器為主,較為保密	混合情況
首次啟動(dòng)	極快 100KB下載量起	慢,看框架和程序整體大小	極快, 看內(nèi)容多少	混合
版本更新	直接覆蓋	客戶(hù)端需下載或重新載入	直接覆蓋	混合情況
搜索引擎	無(wú)	無(wú)	可被收錄	有
被惡意收集數(shù)據(jù)	目前較安全	通過(guò)通信協(xié)議收集	通過(guò)爬蟲(chóng)收集	混合