初探ASP.NET Core 3.x (3) - Web的運作流程和ASP.NET Core的運作結構


本文地址:https://www.cnblogs.com/oberon-zjt0806/p/12215717.html
注意:本篇大量地使用了mermaid繪制圖表,加載需要較長的時間,請見諒

O 前請提要

在第1期中,我們通過一個簡單的過程構建了一個ASP.NET的初始項目,當然,實際上這個項目也是一個.NET Core的項目。因為在第2期中我們提到過,.NET Core的項目本身就基於.NET Framework基礎之上擴展的。
構建一個項目的過程如下:

這里有圖,請稍等片刻

graph LR install(安裝dotnet) create(創建WebApp項目) edit(編輯代碼) trust(信任開發證書) run(運行項目) install-->create create-->edit edit-->trust trust-->run

但是,這只是站在一種不透明的視角下對ASP.NET Core的宏觀開發過程進行的一次概覽和簡單嘗試,我們實際上並不清楚ASP.NET的內部構造和運作機理。

I Web的諸視角

I.1 用戶視角

可以很負責任的說,實際上Web在用戶眼里就是這些東西:一個鼠標+一個鍵盤+一個瀏覽器

是的,用戶只需要使用瀏覽器輸入網址,只要運氣夠好的話(比如網絡通信沒有問題或者遠端也沒什么問題的話)用戶稍等片刻就可以看到目標的頁面。用戶還可以在這個頁面下搞些小動作,比如填個表單啥的。當然,如果不夠走運的話用戶還可能在下午茶的時間享受着美味的404錯誤以及一份做工精致的錯誤提示頁。

這個視角就是所謂的不透明視角,因為只能看到表面上的頁面,后面干什么了我們並不清楚,對於用戶而言,他們也不需要清楚,是吧?

上述內容俗稱前端

I.2 瀏覽器視角

是的,很明顯用戶把所有事情都交給瀏覽器去做了,瀏覽器在面上提供給用戶界面(我們稱之為前端),用戶操作了一番,點了一個提交按鈕。

為了讓用戶在本地上的這些自嗨行為具有網絡上的意義,瀏覽器在應用層上要對用戶的輸入加以處理,用戶產生的信息就這樣從應用層坐電梯一路下到網絡層再下到數據鏈路層把被發送出去。

graph LR user(用戶) browser(瀏覽器) network>網絡] user--操作/數據-->browser browser--請求報文-->network

如果說的再確切一些:

graph LR user(用戶) pages[頁面] script[瀏覽器腳本] network>網絡] subgraph 瀏覽器 pages script script--瀏覽器響應/前端響應/控制-->pages pages--頁面內容-->script end user--操作/數據-->pages pages--請求報文-->network

I.3 服務器視角

歷經若干轉發、代理、可能還包含的重定向等,從瀏覽器發出的請求信息終於到了服務端手里,服務端自然要開始處理數據並反饋用戶所需要的數據,當然了這也就意味着服務端由兩部分構成:

graph LR subgraph Server data(數據源) service("服務程序") end data--數據-->service

實際上用戶在瀏覽器中訪問某個URL得到的頁面的數據來源也是服務器(這部分數據稱為響應(Response)),也就是說,Web應用實際上的處理流程是這樣的:

graph RL user(用戶) browser(瀏覽器) service(服務程序) data("數據<br>(文件、數據庫、...)</span>") subgraph Client user browser end subgraph Server service data end user--訪問URL/操作-->browser browser--URL請求數據-->service service--數據操作-->data data--數據-->service service--響應包-->browser browser--渲染-->user

II ASP.NET Core的角色

上面是一個Web應用程序中各個單位的運作流程,那么在一個ASP.NET的WebApp中ASP.NET Core在其中位於一個什么樣的位置呢??
在前端,ASP.NET Core不再使用傳統的控制器和視圖cshtmlController類)來表示一個前端頁面,取而代之的是使用Razor頁面。Razor是ASP.NET使用的一種頁面標記語言,Razor使得頁面在能夠正確的被解析為瀏覽器可識別的HTML數據的同時允許頁面內嵌入C#或VB代碼來控制界面的動態顯示(類似於JSP或者PHP)。此外,在.NET Core 3.x中又引入了Blazor前端框架來替代JS配合Razor完成前端的交互控制。而用戶將請求發送至服務端時,請求會經過ASP.NET Core提供的請求處理管道上掛載的各中間件(Middleware)進行處理,處理的請求數據移交至服務並決定是否從后端獲取數據。后端數據的獲取是通過Entity Framework Core(EFCore)數據訪問框架與數據庫之間進行交互實現的。

graph LR client(Client) server(Server) subgraph ASP.NET Core請求處理管道 mid1[Middleware1] mid2[Middleware2] midetc[...] end client --> mid1 mid1 --> mid2 mid2 --> midetc midetc --> server server --> midetc midetc--> mid2 mid2 --> mid1 mid1 --> client subgraph Client user(用戶) browser(瀏覽器) subgraph ASP.NET Core Razor razorpage[Razor Pages] blazor[Blazor] end razorpage-->browser blazor-->browser browser-->user user-->browser browser-->blazor end subgraph Server service(服務) data(數據) subgraph ASP.NET Entity Framework Core efc(EFCore) end service-->efc efc-->data data-->efc efc-->service end

II.1 Razor??又中間件??還有EFCore??這都是什么跟什么啊??

不必着急,我們這一部分只是為了簡單了解一下一個ASP.NET Core的WebApp的實際工作流程,這些詳細的內容我們會在接下來的若干期里分別了解。

II.2 我了解過三層架構開發模式,他們都對應着什么呢??

其實ASP.NET Core采取的開發方式仍然是MVC,MVC和三層架構之間確實還是有一定區別(主要是業務邏輯和數據之間耦合程度的差異)。
不過多數情況下,其實MVC和三層架構的主要思想還是一致的,那就是將服務端划分為三塊。

如果將ASP.NET Core套入三層架構的解釋方式中,那么就是:

三層架構 ASP.NET Core
表示層 Razor Pages/Blazor
業務邏輯層 請求處理管道
數據訪問層 Entity Framework Core

III 准備動手

截止到目前為止我們從原理上了解了ASP.NET的運作過程,那么在我們第1期創建的那個初始項目中,這些東西都是如何體現的呢??

To be continued...


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM