.NET Core Blazor 1-Blazor專案檔案分析
本節內容為Blazor的基本檔案
簡介
Blazor是一個使用.NET技術用于代替JavaScript/typescript的前端WEB框架,在前端開發中使用.NET語言進行書寫邏輯有利于我們的性能、可靠性和安全性,并且對于使用.NET開發人員而言,全堆疊的成本更低,
截止文章發布時,.NET Core已經發布了3.1版本,Blazor已經正式發布了Server-Side的框架,基于WebAssembly的Client-Side已經進入測驗,預計2020年發布,Blazor實作了 .NET Standard2.0 ,
Blazor你可以簡單的理解為使用C#寫Angular框架,Blazor是基于組件化開發的一款框架,Blazor的組件和頁面通常使用Razor標記頁的形式進行編碼,因此我們也成為Razor組件(.razor),借助Razor引擎,我們可以將html檔案和C#語法進行切換,不過對于Blazor而言,它的設計思路和傳統MVC是完全不同的,即使他們都使用Razor進行頁面的開發,Blazor更傾向于客戶端UI和邏輯的構成,
Blazor的運行模式
我們知道,Blazor目前有兩種運行方式,他們有著很本質的區別,如下文
Server-Side
Server-Side 也被稱為Blazor服務器,它是完全運行于服務器上面,也就是說客戶端的瀏覽器只是一個空殼頁面,它不包含任何的邏輯和除了首頁(通常會被稱為‘_Host’)以外的任何頁面,該種模式完全托管于服務器,UI的修改已經前端所發生的一切事件都需要傳往服務器進行計算,傳輸的程序使用的是SignalR的方式,

使用這種方式意味著對于服務器的帶寬以及性能要求會極其之高,但是對于一些需要使用到SignalR的應用以及一些訪問量不大的地方使用SignalR也許會有不小的用途,
一次點擊事件在websockets中的傳輸

并且在無操作的情況下,網頁仍需要定期發送心跳包確認服務器狀態,若服務器無回應,則整個網頁停止服務

ClientSide
Client-Side是SPA(Single Page Application)應用,基于一種叫WebAssembly的技術,WebAssembly(wasm)是一個開發的web標準,它是一種很底層的類似于位元組碼的東西,WebAssembly可以通過JavaScript訪問瀏覽器的完整功能,在我們.NET運行在瀏覽器之前,Blazor會提前向瀏覽器發送一個可以運行在WebAssembly上的迷你版本的mono,我們知道.NET中的語言是可以運行在mono之上的,因此我們就等于變相的實作了在瀏覽器中運行.NET,并且所有代碼都是在JavaScript沙盒中運行,也防御了許多不安全操作,
對于客戶端模式,Blazor是將整個專案程式集和運行時(mono)一同發送到了瀏覽器,通過WebAssembly對JavaScript互操作處理DOM節點和相關api的呼叫,

兩種方式對比
事實上兩種方式都有其優缺點,ServerSide在訪問量并不是那么大的時候,或者說你的服務器足夠好的時候,可以很輕松的完成需要的任務,并且在網路聊天這種需要保持長期的網路連接的時候,ServerSide顯然是首選,對于一些博客、或者一些普通的以頁面展示為目的的網站,ClientSide顯然要比ServerSide好一些,但是ClientSide有一個致命的缺點,也就是你的代碼質量必須高,代碼需要精簡,因為你的程式集的大小會影響你的加載速度,因此我們應當盡可能縮小程式集,
兩種方式的瀏覽器支持
ServerSide
- Microsoft Edge
- Mozilla Firefox
- Google Chrome,包括 Android
- Safari,包括 iOS
- Microsoft Internet Explorer 11+
WASM
- Microsoft Edge
- Mozilla Firefox
- Google Chrome,包括 Android
- Safari,包括 iOS
兩種方式的優缺點比較
ServerSide
優點:
- 下載項大小明顯小于 Blazor WebAssembly 應用,且應用加載速度快得多,
- 應用可充分利用服務器功能,包括使用任何與 .NET Core 兼容的 API,
- 服務器上的 .NET Core 用于運行應用,因此除錯等現有 .NET 工具可按預期正常作業,
- 支持瘦客戶端, 例如,Blazor Server 應用適用于不支持 WebAssembly 的瀏覽器以及資源受限的設備,
- 應用的 .NET/C# 代碼庫(其中包括應用的組件代碼)不適用于客戶端,
缺點:
- 通常延遲較高, 每次用戶互動都涉及到網路躍點,
- 不支持脫機作業, 如果客戶端連接失敗,應用會停止作業,
- 如果具有多名用戶,則應用擴縮性存在挑戰, 服務器必須管理多個客戶端連接并處理客戶端狀態,
- 需要 ASP.NET Core 服務器為應用提供服務, 無服務器部署方案不可行(例如通過 CDN 為應用提供服務的方案),
WASM
優點:
- 沒有 .NET 服務器端依賴項, 應用下載到客戶端后即可正常運行,
- 可充分利用客戶端資源和功能,
- 作業可從服務器轉移到客戶端,
- 無需 ASP.NET Core Web 服務器即可托管應用, 無服務器部署方案可行(例如通過 CDN 為應用提供服務的方案),
缺點:
- 應用僅可使用瀏覽器功能,
- 需要可用的客戶端硬體和軟體(例如 WebAssembly 支持),
- 下載項大小較大,應用加載耗時較長,
- .NET 運行時和工具支持不夠完善, 例如,.NET Standard 支持和除錯方面存在限制,
ServerSide專案檔案決議
在微軟提供的模板上面,大體上還是和我們的ASP.NET Core是接近的,在依賴注入中,因為我們利用了Razor來實作C#和html的混合編碼以及我們使用的是ServerSide的Blazor,注入代碼如下:
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddServerSideBlazor();
}
中間件如下
app.UseEndpoints(endpoints =>
{
//匹配我們的signalR的連接
endpoints.MapBlazorHub();
//會自動的去pages/下尋找
endpoints.MapFallbackToPage("/_Host");
});
'_Host.cshtml'中
<app>
<component type="typeof(App)" render-mode="ServerPrerendered" />
</app>
這種方式會自動的去尋找App組件作為根組件,并且還有另一種方式
<app>
@(await Html.RenderComponentAsync<App>(RenderMode.ServerPrerendered))
</app>
這種方式可以無縫將你的MVC或者其他模式下的ASP.NET Core應用遷移到Blazor,這種方式是設定預渲染,使用Html.RenderComponentAsync
而對于其他檔案的布局是和我們經典的MVC模式一樣的,
ClientSide專案檔案決議
對于ClientSide,就類似我們使用ASP.NET Core進行SPA應用開發的格式,對于Client的頁面需要單獨的一個專案去村,內部和普通的mvc或者serverside的寫法類似,但是需要將中間件的服務修改以及我們的WebHost進行修改
// 替換為IBlazorApplicationBuilder
public void Configure(IBlazorApplicationBuilder app)
{
//添加根組件
app.AddComponent<App>("app");
}
// 更換webhost
public static IWebAssemblyHostBuilder CreateHostBuilder(string[] args) =>
BlazorWebAssemblyHost.CreateDefaultBuilder()
.UseBlazorStartup<Startup>();
隨后你需要添加一個Server專案用于啟動我們的服務,只需要在依賴注入中添加以下配置,中間件中激活我們的Blazor即可,
services.AddResponseCompression(options =>
{
options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[]
{
MediaTypeNames.Application.Octet,
WasmMediaTypeNames.Application.Wasm,
});
});
// 中間件
app.UseBlazor<Client.Startup>();
如果我的文章幫助了您,請您在github.NETCoreGuide專案幫我點一個star,在博客園中點一個關注和推薦,
Github
BiliBili主頁
WarrenRyan'sBlog
博客園
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/86548.html
標籤:.NET Core
