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

本文地址：http://www.javashuo.com/article/p-kmyltmcx-dw.html
注意：本篇大量地使用了mermaid繪製圖表，加載須要較長的時間，請見諒

[TOC]

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再也不使用傳統的控制器和視圖（cshtml和Controller類）來表示一個前端頁面，取而代之的是使用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...