初探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...