本文地址：https://www.cnblogs.com/oberon-zjt0806/p/12215717.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==>edit==>trust==>run

但是，这只是站在一种不透明的视角下对ASP.NET Core的宏观开发过程进行的一次概览和简单尝试，我们实际上并不清楚ASP.NET的内部构造和运作机理。

I Web的诸视角

I.1 用户视角

可以很负责任的说，实际上Web在用户眼里就是这些东西：一个鼠标+一个键盘+一个浏览器

是的，用户只需要使用浏览器输入网址，只要运气够好的话（比如网络通信没有问题或者远端也没什么问题的话）用户稍等片刻就可以看到目标的页面。用户还可以在这个页面下搞些小动作，比如填个表单啥的。当然，如果不够走运的话用户还可能在下午茶的时间享受着美味的404错误以及一份做工精致的错误提示页。

这个视角就是所谓的不透明视角，因为只能看到表面上的页面，后面干什么了我们并不清楚，对于用户而言，他们也不需要清楚，是吧？

I.2 浏览器视角

是的，很明显用户把所有事情都交给浏览器去做了，浏览器在面上提供给用户界面（我们称之为前端），用户操作了一番，点了一个提交按钮。

为了让用户在本地上的这些自嗨行为具有网络上的意义，浏览器在应用层上要对用户的输入加以处理，用户产生的信息就这样从应用层坐电梯一路下到网络层再下到数据链路层把被发送出去。

graph LR
user(用户)
browser(浏览器)
network>网络]
user--操作/数据-->browser--请求报文-->network

如果说的再确切一些：

graph LR
user(用户)
pages[页面]
script[浏览器脚本]
network>网络]

subgraph 浏览器
pages
script
script--浏览器响应/前端响应/控制-->pages
pages--页面内容-->script
end

user--操作/数据-->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--URL请求数据-->service--数据操作-->data--数据-->service--响应包-->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 --> mid2 --> midetc --> server
server --> midetc --> mid2 --> 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-->data
data-->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...

巴特西

初探ASP.NET Core 3.x (3) - Web的运作流程和ASP.NET Core的运作结构