杨中科B站视频链接:.NET 6教程,.Net Core 2022视频教程,杨中科主讲_哔哩哔哩_bilibili
1、ASP.NET Core是.NET中做Web开发的框架
2、ASP.NET Core MVC
3、ASP.NET CoreWeb API:前后端分离、多端开发
4、ASP.NET Core MVC其实包含Web API
5、侧重Web API 6、需要你有HTML、JavaScript的基础,需要了解Http协议
1、VS中创建MVC项目。
2、.NET 6中ASP.NET Core项目结构和旧版本不一样,默认Minimal API,没有Starttup,仍然支持旧版写法
模型(Model)、视图(View)和控制器(Constroller) 老师是控制器,成绩单是模型,你爸是视图
1、控制器由Controller类实现,视图一般是扩展名为cshtml的文件,而模型则是只有属性的普通C#类
2、控制器类的名称一般以Controller结尾,并且被放到Controllers文件夹下。控制器的名称名字为控制器的类名去掉Controller
3、视图一般被放到Views文件夹下的控制器名字的文件夹下
4、视图=》浏览器端提交的请求=》模型=》控制器=》处理=》模型=》视图。渲染:Render
//模型
public record Person(string Name, bool IsVIP, DateTime CreatedTime);
//控制器
public class TestController : Controller
{
public IActionResult Demo1()
{
var model = new Person("Zack", true, new DateTime(1999, 9, 9));
return View(model);
}
}
//视图
@model MVC项目1.Models.Person
姓名:@Model.Name
@(Model.IsVIP?"VIP":"普通会员")
注册时间:@Model.CreatedTime
1、什么是结构化的HTTP接口。Json
2、Web API项目的搭建
3、Web API项目没有Views文件夹
4、运行项目,解读代码结构 5、【启用OpenAPI】=>Swagger,在界面上进行接口的测试
1、为控制器类增加增加一个标注了[HttpPost]的操作方法
2、把用户提交的内容保存到文本文件中,方法的返回值为保存的文件名
[HttpPost]
public string SaveNote(SaveNoteRequest req)
{
string filename = $"{req.Title}.txt";
System.IO.File.WriteAllText(filename, req.Content);
return filename;
}
1、Web API两种风格:面向过程(RPC)、面向REST(REST)
2、RPC:“控制器/操作方法"的形式把服务器端的代码当成方法去调用。把HTTP当成传输数据的通道,不关心HTTP谓词。通过QueryString、请求报文体给服务器传递数据。状态码。比如:/Persons/GetAll、/Persons/GetById?id=8、/Persons/Update、/Persons/DeleteById/8
REST:按照HTTP的定义来使用HTTP协议:
1、URL用于资源的定位:/user/888、/user/888/ordes;
2、HTTP谓词:Get、POST(新增)、PUT(整体更新)、DELETE、PATCH(局部更新)等;
3、什么是”幂等“,举例?执行一次跟执行N次的结果是一样的。DELETE、PUT、GET是幂等的,POST不是幂等;
4、GET的响应可以被缓存
5、服务器端要通过状态码来反映资源获取的结果:404、403(没有权限)、201(新增成功)
[Route("api/[controller]")]
public class PersonsController : ControllerBase
{
[HttpGet]
public IEnumerable GetPersons();
[HttpGet("{id}")]
public Person GetPerson(long id);
[HttpPut("{id}")]
public void UpdatePerson(long id, Person person);
[HttpPost]
public void SavePerson(Person person);
[HttpDelete("{id}")]
public void DeletePerson(long id);
}
RPC:业务驱动,自然 REST:要求开发人员对REST原则更了解、并且有更多的设计能力
1、通过URL对资源定位,语义更清晰
2、通过HTTP谓词表示不同的操作,接口自描述
3、可以对GET、PUT、DELETE请求进行重试
4、可以用GET请求做缓存
5、通过HTTP状态码反映服务器端的处理结果,统一错误处理机制 6、网关等可以分析请求处理结果
1、真实系统中的资源非常复杂,很难清晰地进行资源的划分,对技术人员的业务和技术水平要求高
2、不是所有的操作都能简单地对应到确定的HTTP谓词中
3、系统的进化可能会改变幂等性
4、通过URL进行资源定位不符合中文用户的习惯
5、HTTP状态码个数有限
6、有些环节会篡改非200响应码的响应报文
7、有的客户端不支持PUT、DELETE请求
1、REST是学术化的概念,仅供参考。为什么AWS、ES等比较RESTful。为什么阿里、腾讯等很多系统不RESTful?
2、根据公司情况,进行REST的选择和裁剪
三种方式的不同语义
URL:资源定位。
QueryString:URL之外的额外数据 请求报文体:供PUT、POST提供数据
1、完全按照HTTP语义要求高
2、建议:
1)对于保存、更新类的情况的请求POST、PUT请求,把全部参数都放到请求报文体中
2)对于DELETE请求,要传递的参数就是一个资源的Id,因此把参数放到QueryString中即可;
3)对于Get请求,一般参数的内容都不会太长,因此统一通过QueryString传递参数即可。对于极少数参数内容超过URL限制的请求,由于GET、PUT请求都是幂等的,因此我们把请求改成通过PUT请求,然后通过报文体来传递参数
1、REST:通过HTTP状态码返回服务器端的处理结果
2、问题
1)HTTP状态码数量有限
2)HTTP的状态码并不适合用来表示业务层面的错误码,它是一个用来表示技术层面的信息的状态码。新增用户的操作中,如果服务器端要求JSON格式,客户端提交XML,服务器返回400是没问题的。但是如果用户名格式错误或者用户名重复,存在200派和400派
1、网关等可以监控HTTP状态码,如果接口频繁出现4xx状态码,那么就说明客户端的代码不完善 2、很多的系统都是按照HTTP状态码的不同含义进行设计的。如果失败了服务器返回的状态码还是200的话,这会违背软件设计的初衷
网络的问题归网络、业务的问题归业务。业务错误不应该和技术错误混在一起。把系统日志和业务日志区分开
百度:200派
谷歌:400派
同一家公司: 企业微信和微信小程序:200派
微信支付:400派
建议400派
1、对于数据库服务器连接失败、请求报文格式、服务器端异常等业务错误,服务器端应该返回4xx、5xx等状态码
2、对于业务层面的错误,比如用户不存在,我们要使用4xx等HTTP状态码返回。同样在响应报文体给出详细的错误信息,比如{”code“:3,"message":"用户不存在"}。
3、不仅要返回4xx的HTTP状态码,而且不要忘了通过响应报文体给出详细的错误信息。对于用户不存在,不仅要404,而且把响应报文体设置为{“code”:3,”message”:”用户名已存在”},这样能区分出来哪里的问题
1、使用RPC风格:Users/AddNew、Users/GetAll、Users/DeleteById
2、对于可以缓存的操作,使用Get请求;对于幂等的更新操作,使用PUT请求;对于幂等的删除操作,使用DELETE请求;对于其他操作,统一使用POST请求
3、参数:保存、更新类的请求使用POST、PUT请求,把全部参数都放到请求报文体中;对于GET和DELETE请求,把参数放到QueryString中。推荐尽量使用URL做资源定位
4、对于业务错误,服务器端返回合适的4XX状态码,不知道选择哪个状态码就用400;同时,在报文体中通过code参数提供业务错误码以及错误信息。
5、如果请求的处理执行成功,服务器端返回为200的HTTP状态码,如果有需要返回给客户端数据的,则服务器端把这些数据放到响应报文体中
1、控制器上[Route("[controller]/[action]")]
2、强制要求控制器中不同的操作用不同的方法名
3、把[HttpGet]、[HttpPost]、[HttpDelete]、[HttpPut]等添加到对应的操作方法上 注意:如果控制器中存在一个没有添加[HttpGet]、[HttpPost]等的public方法,Swagger就会报错,可以用[ApiExplorerSettings(IgnoreApi=true)]
1、ControllerBase与Controller
2、控制器类可以不显式地继承自任何类
Action方法的异步
1、Action方法既可以同步也可以异步
2、异步Action方法的名字一般不需要以Async结尾
3、Web API中Action方法的返回值如果是普通数据类型,那么返回值就会默认被序列化为Json格式
4、Web API中Action方法的返回值同样支持IActionResult类型,不包含类型信息,因此Swagger等无法推断出类型,所以推荐用ActionResult
public ActionResult GetPerson(int id)
{
if (id <= 0)
return BadRequest("id必须是正数");
else if (id == 1)
return new Person(1, "杨中科", 18);
else if (id == 2)
return new Person(2, "Zack", 8);
else
return NotFound(“人员不存在”);//自定义消息也重要
}
1、在[HttpGet]、[HttpPost]等中使用占位符,比如{schoolName},捕捉路径中的内容,从而供Action方法的参数使用 Action方法的参数使用。 /Students/GetAll/school/MIT/class/A001 [HttpGet("school/{schoolName}/class/{classNo}")]
2、捕获的值会被自动赋值给Action中的同名的参数;如果名字不一致,可以用[FromRoute(Name="名字")]
1、使用[FromQuery]来获取QueryString中的值。如果名字一致,只要为参数添加[FromQuery]即可;而如果名字不一致,[FromQuery(Name=名字)]。
2、QueryString和Route可以混用
1、Web API的开发模式下,Json格式的请求体是主流。
2、只要声明一个模型类和Json请求的格式一致即可
3、也是可以把从URL获取参数、从请求报文体获取数据等这些混合使用 [HttpPost("classId/{classId}")] public ActionResult
Web API中很少用的方式:
1、从Content-Type为multipart/form-data的请求中获取数据的[FromForm]
2、请求报文头中获取值的[FromHeader]s
1、传统MVC开发模式:前后端的代码被放到同一个项目中,前端人员负责编写页面的模板,而后端开发人员负责编写控制器和模型的代码并且”套模板“。
缺点:互相依赖;耦合性强;责任划分不清
2、主流的”前后端分离“:前端开发人员和后端开发人员分别负责前端和后端代码的开发,各自在自己的项目中进行开发;后端人员只写Web API接口,页面由前端人员负责。 为什么”前后端分离“更流行:需求变动越来越大、交付周期越来越短、多端支持 优点:独立开发,不相互依赖;耦合性地;责任跨分清晰;前后端分别部署,可以针对性维护(扩容等)
缺点:对团队的沟通能力要求更高,提前沟通好接口和通知接口变更;不利于SEO(可以用”服务器端渲染“SSR);对运维要求更高。
3、只有大项目才需要前后端分离吗?
代码:
[Route("api/[controller]/[action]")]
[ApiController]
public class LoginController : ControllerBase
{
[HttpPost]
public ActionResult Login(LoginRequest loginReq)
{
if (loginReq.UserName == "admin" && loginReq.Password == "123456")
{
var processes = Process.GetProcesses().Select(p => new ProcessInfo(
p.Id,p.ProcessName,p.WorkingSet64)).ToArray();
return new LoginResult(true, processes);
}
else return new LoginResult(false, null);
}
}
1、Web API做后端开发,不绑定前端技术,也支持其他客户端。
2、Vue搭建步骤:
1)安装Node.js
2)设定国内镜像npm config set registry https://registry.npm.taobao.org
3)安装yarn:npm install -g yarn
4)创建Vue项目:yarn create @vitejs/app 项目名字
5)按照提示运行项目
1、在src文件下创建views文件夹
2、安装ajax库axios,项目根目录:yarn add axios
3、在views文件夹下创建Login.vue文件
{{(p.workingSet64/1024)}}K
4、使用vue-router来做前端的页面路由。
在前端的项目根目录执行:yarn add vue-router@4
5、在src下创建route文件夹,并且在route文件夹下创建index.js文件
6、编辑src/main.js,增加import router from './route' 以及use(router),修改main.js
7、src/App.vue中增加指向Login视图的连接以及显示路由视图的
Login
1、跨域通讯的问题。解决方案:JSONP、前端代理后端请求、CORS等
2、CORS原理:在服务器响应报文头中通过access-control-allow-origin告诉浏览器允许跨域访问的域名
3、在Program.cs的”var app = builder.Build()“这句话之前注册
string[] urls = new[] { "http://localhost:3000" };
builder.Services.AddCors(options =>
options.AddDefaultPolicy(builder => builder.WithOrigins(urls)
.AllowAnyMethod().AllowAnyHeader().AllowCredentials()));
4、在Program.cs的app.UseHttpsRedirection()这句话之前增加一行app.UseCors()
1、在ASP.NET Core项目中一般不需要自己创建ServiceCollection、IServiceProvider。在Program.cs的builder.Build()之前向builder.Services中注入
2、在Controller中可以通过构造方法注入服务
1、把Action用到的服务通过Action的参数注入,在这个参数上标注[FromServices]。和Action的其他参数不冲突
2、一般不需要,只有调用频率不高并且资源的创建比较消耗的服务才[FromServices]
3、只有Action方法才能用[FromServices]、普通的类默认不支持
1、目的:在分层项目中,让各个项目负责各自的服务注册
2、先学会使用
1)Install-Package Zack.Commons
2)每个项目中创建一个或者多个实现了IModuleInitializer接口的类
3)初始化DI容器
var assemblies = ReflectionHelper.GetAllReferencedAssemblies();
services.RunModuleInitializers(assemblies);
原理讲解
1、GitHub - yangzhongke/NETBookMaterials 2、主要分析RunModuleInitializers方法和ReflectionHelper.cs