.net 温故知新:【1】 .Net 5 基本概念和开发环境搭建 - XSpringSun - 博客园

mikel阅读(420)

来源: .net 温故知新:【1】 .Net 5 基本概念和开发环境搭建 – XSpringSun – 博客园

最近一两年搞了很多其它事情,.net web方面的基本没做,之前做过几个小的项目零星的学习了些,从.net core 发布后其实都没正真的系统学习过。
就是上手做项目,平时也有关注和看些资料,所以项目写点业务逻辑还是没问题的,最近琢磨着重新系统学习下.net。
因为以后不叫.net core统一叫.net x, 所以就从当前稳定版本.net 5 开始吧,反正.net 6 还没正式发布而且也不会对体系进行大改,说不定搞着搞着就到6了,所以标题写成.net 5+。
平时除了工作生活也没太多空闲时间,对于我来说可能是个漫长的学习过程。熟话说开篇有益嘛,希望不会太监,一是给自己做学习笔记以免遗忘,二是和新同学一起学习,岂不快哉。
我们第一步从.net 开发环境搞起。

.NET SDK 和 运行时

首先我们先了解下.net sdk和运行时的概念。

.NET SDK 是一组用于开发和运行 .NET 应用程序的库和工具

SDK 下载包括以下组件:

  • NET CLI。 可用于本地开发和持续集成脚本的命令行工具。
  • dotnet 驱动程序。 用于运行依赖于框架的应用的 CLI 命令。
  • Roslyn 和 F# 编程语言编译器。
  • MSBuild 生成引擎。
  • .NET 运行时。 提供类型系统、程序集加载、垃圾回收器、本机互操作和其他基本服务。
  • 运行时库。 提供基元数据类型和基本实用程序。
  • ASP.NET Core 运行时。 为连接 Internet 的应用(如 Web 应用、IoT 应用和移动后端)提供基本服务。
  • 桌面运行时。 为 Windows 桌面应用(包括 Windows 窗体和 WPF)提供基本服务。

运行时下载包括以下组件:

  • (可选)桌面或 ASP.NET Core 运行时。
  • .NET 运行时。 提供类型系统、程序集加载、垃圾回收器、本机互操作和其他基本服务。
  • 运行时库。 提供基元数据类型和基本实用程序。
  • dotnet 驱动程序。 用于运行依赖于框架的应用的 CLI 命令。

这里要注意[运行时]和[.NET运行时],运行时就是上面包含的那些东西,.NET运行时包含在运行时里面。
.Net 运行时也就是那个CLR,运行时库就是基类库 (BCL),这些名字确实挺迷惑的,也许我们平时说的.net 运行时≈运行时,但是在理解概念的时候要搞清楚。

.NET CLR 是包含 Windows、macOS 和 Linux 支持的跨平台运行时。 CLR 处理内存分配和管理。 CLR 也是一个虚拟机,不仅可执行应用,还可使用实时 JIT 编译器生成和编译代码。
运行时库也称为框架库或基类库 (BCL)。 这些库为许多常规用途类型和特定于工作负载的类型和实用工具功能提供实现。

你可以看到 SDK 是包含运行时的,SDK还包含了一个重要的东西就是CLI,CLI工具是用于开发、生成、运行和发布 .NET 应用程序的跨平台工具链。
例如如下一行代码命令就是CLI 帮我们干事,在当前目录下创建 C# 控制台应用程序项目:

dotnet new console 

简单点说就是SDK可以让我们开发程序,运行时让我们可以运行写好的程序,当然安装了SDK就没必要再装运行时了。
如果和java做类比,sdk 相当于 jdk,运行时 相当于 jre。
当然我们一般不会用cli开发,因为我们有更好的工具 visual studio。

SDK 安装

SDK安装有两种方式,第一种是通过工具安装的时候一起安装,第二种是自己下载SDK包安装。

1、使用 Visual Studio 安装

visual studio 2019 下载

不同目标 .NET SDK 版本所需的 Visual Studio 最低版本。

对于.net 5来说则最少需要 visual studio 2019 版本 16.8 。

如果你已安装 Visual Studio,则可以使用以下步骤检查你的版本。
打开 Visual Studio。
选择“帮助” > “Microsoft Visual Studio”。
从“关于”对话框中读取版本号。

我本地已经安装了visual studio 2019 本来准备通过更新修改vs方式测试安装的。但是我本地环境vs有问题,一直报错。

没有装的同学可以直接下载,然后按需选择功能直接安装就OK。
捣鼓了下,没办法修复,无法升级。所以最后得重新安装,因为.net 5 最低支持16.8,我的16.7!。
如果没办法卸载vs 使用安装器目录下C:\Program Files (x86)\Microsoft Visual Studio\Installer 运行setup.exe,然后再启动installer安装。

2、下载并手动安装

.NET 5.0 下载

这是第二种方式,如果你不需要vs的话可以用这种方式,直接下载安装SDK。
然后就可以使用CLI创建项目了,应该很少人会不使用工具去编程,毕竟没啥理由。

.NET 5 项目创建

在卸载重装了了Visual Studio 2019 后我们看看创建项目。
创建一个控制台程序,如下图可以看到有两个选项,一个是.net Framework,一个是.net core上运行的。
不知道后面正式版VS2022会不会修改这个名称叫法,毕竟后面不再叫.net core了。

但是我们选了.net core 后可以选择我们的目标框架,如果装了多个版本。

到此我们的.net 5 开发环境就搭建起来了,下一次我们再来探究下.net framwork,.net 5 和 .net standard的概念和区别。

.net 温故知新:【8】.NET 中的配置从xml转向json - XSpringSun - 博客园

mikel阅读(404)

来源: .net 温故知新:【8】.NET 中的配置从xml转向json – XSpringSun – 博客园

一、配置概述

在.net framework平台中我们常见的也是最熟悉的就是.config文件作为配置,控制台桌面程序是App.config,Web就是web.config,里面的配置格式为xml格式。
image

在xml里面有系统生成的配置项,也有我们自己添加的一些配置,最常用的就是appSettings节点,用来配置数据库连接和参数。
使用的话就引用包System.Configuration.ConfigurationManager 之后取里面的配置信息:System.Configuration.ConfigurationManager.AppSettings["ConnectionString"]

随着技术的发展这种配置方式显得冗余复杂,如果配置项太多层级关系参数表达凌乱,在.net core开始也将配置的格式默认成了json格式,包括现在很多的其它配置也是支持的,比如java中常用的yaml格式,为什么能支持这么多读取源和格式,其实质在于配置提供程序
目前.NET 中的配置是使用一个或多个配置提供程序执行的。 配置提供程序使用各种配置源从键值对读取配置数据,这些配置程序稍后我们会看到,读取的配置源可以是如下这些:

  • 设置文件,appsettings.json
  • 环境变量
  • Azure Key Vault
  • Azure 应用配置
  • 命令行参数
  • 已安装或已创建的自定义提供程序
  • 目录文件
  • 内存中的 .NET 对象
  • 第三方提供程序

二、配置初识

IConfiguration 接口是所有配置源的单个表示形式,给定一个或多个配置源,IConfiguration 类型提供配置数据的统一视图。
image

上图我们可能没有直观的感受,现在写一个例子来看看

(1). 新建控制台应用程序:
创建控制台使用的是.net 6.0 框架,vs 2022。
安装 Microsoft.Extensions.Configuration.Json NuGet 包,该包提供json配置文件读取。

Install-Package Microsoft.Extensions.Configuration.Json

image

(2). 添加appsettings.json 文件

{
  "person": {
    "name": "XSpringSun",
    "age": 18
  }
}

(3). 使用json提供程序读取json配置
new一个ConfigurationBuilder,添加json配置,AddJsonFile是在包中的IConfigurationBuilder扩展方法,其它配置提供程序也是用这种扩展方法实现。

        static void Main(string[] args)
        {

            IConfiguration configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json")
                .Build();

            Console.WriteLine(configuration["person:name"]);
            Console.WriteLine(configuration["person:age"]);

            Console.WriteLine("Hello, World!");
            Console.ReadLine();
        }

image

可以看到已经取到json配置文件中的值了,配置值可以包含分层数据。 分层对象使用配置键中的 : 分隔符表示。在下面的调试对象中我们可以看到实际configuration的Providers 提供程序数组有一个值,就是我们的JsonConfigurationProvider,并且JsonConfigurationProvider里面已经读取了json的数据存储在Data数组中。

对于如上几行代码干了什么呢:

  • 将 ConfigurationBuilder 实例化(new ConfigurationBuilder)。
  • 添加 “appsettings.json” 文件,由 JSON 配置提供程序识别(AddJsonFile(“appsettings.json”))。
  • 使用 configuration 实例获取所需的配置

三、选项模式

这样已经实现json进行配置读取,但是取值的方式似乎和以前没什么太大变法,所以.net提供了选项模式,选项模式就是使用类来提供对相关设置组的强类型访问。
我们创建一个Config类用来转换json:

namespace ConfigDemo
{
    public class Config
    {
        public Person? person { get; set; }
    }

    public class Person {
        public string? name { get; set; }
        public int age { get; set; }
    }
}

绑定配置

IConfiguration configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json")
                .Build();


            Config options = new Config();
            ConfigurationBinder.Bind(configuration, options);

            Person person = configuration.GetSection("person").Get<Person>();

            Console.WriteLine(options.person.name);
            Console.WriteLine(options.person.age);

            Console.WriteLine("-----------GetSection获取-------------");
            Console.WriteLine(person.name);
            Console.WriteLine(person.age);

image

用了两种方式获取配置,第一种使用ConfigurationBinder.Bind()将整个配置绑定到对象Config上,另外一种是使用IConfiguration的GetSection().Get<T>()并返回指定的类型。两种方式都可以使用,看实际需求和用途。

四、选项依赖注入

在控制台程序中我们引用DI注入包,然后演示下如何进行配置的注入。关于DI和IOC不清楚的看我上篇文章.net 温故知新:【7】IOC控制反转,DI依赖注入

  • 新建一个测试类TestOptionDI
    public class TestOptionDI
    {
        private readonly IOptionsSnapshot<Config> _options;
        public TestOptionDI(IOptionsSnapshot<Config> options)
        {
            _options = options;
        }

        public void Test()
        {
            Console.WriteLine("DI测试输出:");
            Console.WriteLine($"姓名:{_options.Value.person.name}");
            Console.WriteLine($"年龄:{_options.Value.person.age}");
        }
    }

在测试类中我们使用IOptionsSnapshot<T>接口作为依赖注入,还有其它不同定义的接口用来配置注入,关于选项接口:。

image

不同接口可以配合读取配置的不同方式起作用,IOptionsSnapshot接口可以在配置文件改变后不同作用域进行刷新配置。接着我们修改main方法,引入DI,并将AddJsonFile方法的参数reloadOnChange设置为true,optional参数是否验证文件存在,建议开发时都设置为true,这样如果文件有问题会进行报错。
注入配置这句services.AddOptions().Configure<Config>(e=>configuration.Bind(e))是关键,通过容器调用AddOptions方法注册,然后Configure方法里面是一个委托方法,该委托的作用就是将配置的信息绑定到Config类型的参数e上。注册到容器的泛型选项接口,这样在TestOptionDI类构造函数注入就能注入IOptionsSnapshot了,这里有点绕。

        static void Main(string[] args)
        {

            IConfiguration configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json",optional:true,reloadOnChange:true)
                .Build();
            
            //IServiceCollection 服务
            ServiceCollection services = new ServiceCollection();
            //注入配置
            services.AddOptions().Configure<Config>(e=>configuration.Bind(e));
            //注入TestOptionDI
            services.AddScoped<TestOptionDI>();

            using (var provider = services.BuildServiceProvider())
            {
                //获取服务
                var testOption = provider.GetRequiredService<TestOptionDI>();
                testOption.Test();
            }
            Console.ReadLine();
        }

image

为了测试IOptionsSnapshot接口在不同作用域会刷新配置,我们修改下main方法,用一个while循环在ReadLine时修改json文件值,不同的Scope里进行打印。

            using (var provider = services.BuildServiceProvider())
            {
                while (true)
                {
                    using (var scope = provider.CreateScope())
                    {
                        //获取服务
                        var testOption = scope.ServiceProvider.GetRequiredService<TestOptionDI>();
                        testOption.Test();
                    }
                    Console.ReadLine();
                }
            }

image

这个功能在web中使用很方便,因为框架的一次请求就是一个作用域,所以我们修改了配置,下次请求就能生效了,而不用重启服务。

五、其它配置

如最开始所说,不仅能配置json文件,由于各种提供程序,还可以配置其它的,但是根据配置的顺序会进行覆盖。我们只添加一个环境变量配置演示下:
首先添加提供程序包:Install-Package Microsoft.Extensions.Configuration.EnvironmentVariables
然后添加环境变量配置代码AddEnvironmentVariables()

IConfiguration configuration = new ConfigurationBuilder()
                .AddJsonFile("appsettings.json",optional:true,reloadOnChange:true)
                .AddEnvironmentVariables()
                .Build();

在VS中配置临时环境变量
image

这里有个扁平化配置,就是表示层级用冒号person:age
image

六、托管模式

对于web项目我们没有进行这么多操作它是怎么配置的呢,其实框架已经自动帮我们做了,其它非web项目也可以使用这种托管模式,在Microsoft.Extensions.Hosting 包中,只需要使用简单的代码就能配置好。

IHost host = Host.CreateDefaultBuilder(args).Build();
await host.RunAsync();

其加载配置的优先级:
image
通过分析我们对整个配置如何运行的机制有了一个大体的了解,如果想详细了解托管模式的还是建议看官方文档:.NET配置

.net 温故知新【17】:Asp.Net Core WebAPI 中间件 - XSpringSun - 博客园

mikel阅读(465)

来源: .net 温故知新【17】:Asp.Net Core WebAPI 中间件 – XSpringSun – 博客园

一、前言

到这篇文章为止,关于.NET “温故知新”系列的基础知识就完结了,从这一系列的系统回顾和再学习,对于.NET core、ASP.NET CORE又有了一个新的认识。

不光是从使用,还包括这些知识点的原理,虽然深入原理谈不上,但对于日常使用也够了,我想的是知其然,知其所以然。

在实际开发过程中可能是知道怎么使用就行,但系统学习了这些基本的框架、组件、或者说原理后,对于我们软件设计、开发、扩展和解决问题还是有帮助的。

刚好到2023新年前赶着写完,也算对自己这个系列的一个交代,实际上我平时基本不使用ASP.NET CORE,目前我主要开发桌面程序,还是用的winform。

写这个系列的初衷是想紧跟.NET的发展进程,同时储备基础知识,平时还搞一些微服务(Java)、NLP、OCR、知识图谱、前端(Vue3),只要需要反正啥都搞,没必要固执,技术只是手段,不是目的。

那么接下来就继续简单的梳理一下中间件,欢迎对这个系列拍砖!

二、中间件

中间件是一种装配到应用管道以处理请求和响应的软件。 每个组件:

  • 选择是否将请求传递到管道中的下一个组件。
  • 可在管道中的下一个组件前后执行工作。

这个是关于中间件概念的概括,官方的概括是相当精准,那么我们就围绕管道、传递、组件来看看中间件。

请求委托用于生成请求管道。 请求委托处理每个 HTTP 请求。使用 Run、Map 和 Use 扩展方法来配置请求委托。

我们照例新建一个ASP.NET CORE Web API 项目:WebAPI_Middleware

namespace WebAPI_Middleware
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

在Program.cs 中我们看到前面部分builder是配置依赖注入的东西,这部分可以参看.net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI 。

app 使用Use扩展用于中间件添加到管道中

Map 基于给定请求路径的匹配项来创建请求管道分支

Run 委托始终为终端,用于终止管道。

中间件的执行顺序过程如下:

image

三、Map

我们将上面自动创建的东西全都删除,用Map来匹配路由,然后通过不同的代理处理请求。

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();
           
            //匹配map1 请求
            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));
            //匹配map2 请求
            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));

            app.Run();
        }
    }
  • 请求map1 我们输出:map1 run

image

  • 请求map2 我们输出:map2 run

image

Asp.Net Core MapControllers 的扩展方法也是类似道理,用来匹配路由调用处理程序。

四、Run

在上面的 Map 后面我们使用的处理方法中 Run 用于终止管道。也就是说在该管道中如果调用了 Run 那么就直接返回了,即使你后面还添加了 Use 也不会执行。

app.Run(async context =>
{
    await context.Response.WriteAsync("map1 run");
});

Map 相当于是迎客进门,Map 上了就用指定的管道进行处理,如果没有 Map 上就调用主管道,也就是主管道上的其他中间件也会执行处理。比如我们再加一个 Run 用于没匹配上路由也输出点信息。

image

加了context.Response.ContentType = "text/plain; charset=utf-8"; 不然中文会乱码。

image

因为 Run 是终结点,那这个管道中我还想加其他处理怎么办呢,这个时候就该轮到 Use 出场了。

五、Use

用 Use 将多个请求委托链接在一起。 next 参数表示管道中的下一个委托。 可通过不调用 next 参数使管道短路。

首先我们在外面添加两个 Use,不放到 Map 中,这样的话就只有未匹配到的路由会调用

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();

            

            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));

            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));
            //Use1
            app.Use(async (context, next) =>
            {
                context.Response.ContentType = "text/plain; charset=utf-8";

                await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);

            });
            
            //Use2
            app.Use(async (context, next) =>
            {
                await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);

            });
            //结束管道处理
            app.Run(async context =>
            {
                await context.Response.WriteAsync("未匹配处理!\r\n", Encoding.UTF8);
            });

            app.Run();
        }
    }

最后执行的路径和最开始的图是一致的。

image

为什么将context.Response.ContentType = "text/plain; charset=utf-8"; 放到第一个 Use 呢,因为如果放到 Run 里面会报错,改变了 Header 标头。所以理论上也不要在 Use 里面发送响应WriteAsync,此处为了演示所以这么写。

image

六、中间件类

上面的代理方法可以移动到类中,这个类就是中间件类。中间件类需要如下要求:

  • 具有类型为 RequestDelegate 的参数的公共构造函数。
  • 名为 Invoke 或 InvokeAsync 的公共方法。 此方法必须:
    返回 Task。
    接受类型 HttpContext 的第一个参数。

构造函数和 Invoke/InvokeAsync 的其他参数由依赖关系注入 (DI) 填充。

将上面的未匹配路由处理逻辑移动到中间件类中:

  • TestMiddleware1:
    public class TestMiddleware1
    {
        private readonly RequestDelegate _next;

        public TestMiddleware1(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {

            context.Response.ContentType = "text/plain; charset=utf-8";

            await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • TestMiddleware2
    public class TestMiddleware2
    {
        private readonly RequestDelegate _next;

        public TestMiddleware2(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {


            await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • Program
    image
  • 运行
    image

此处的中间件使用有顺序问题,如果我先app.UseMiddleware<TestMiddleware2>() 因为 TestMiddleware1 修改了标头,根据约定是不允许的,所以程序是有报错。

image

因此中间件组件的顺序定义了针对请求调用这些组件的顺序,以及响应的相反顺序。 此顺序对于安全性、性能和功能至关重要。

七、中间件顺序

image

以上是内置中间件的默认顺序规则,具体如何使用内置中间件,可参阅官方资料。

八、写在最后

以上就是关于中间件的部分知识,结合我自己的理解做了前后衔接的梳理逻辑。

官方网站更多的是讲解每个知识点的细节,前后需要结合起来理解,当然我还是强烈建议跟着官方文档学习,而且是最权威最可信的:ASP.NET Core 中间件

这个系列历时2年,工作生活都比较忙,也有放纵啥事不相干的时候,中间断断续续的,总算是坚持完了。很多东西就是这样,累了就休息一下贵在坚持,即使再慢,积累的成果也有收获。

.net 温故知新【16】:Asp.Net Core WebAPI 筛选器 - XSpringSun - 博客园

mikel阅读(446)

来源: .net 温故知新【16】:Asp.Net Core WebAPI 筛选器 – XSpringSun – 博客园

一、筛选器

通过使用筛选器可在请求处理管道中的特定阶段之前或之后运行代码。

这即是我们经常听到的面向切面编程AOP(Aspect Oriented Programming)技术,AOP通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。

筛选器在 ASP.NET Core 操作调用管道(有时称为筛选器管道)内运行。 筛选器管道在 ASP.NET Core 选择了要执行的操作之后运行:
image

ASP.NET Core 关注的切面点 包括错误处理、缓存、配置、授权和日志记录筛选器,这个是说通过筛选器可以实现对以上关注点的一些操作。

在Asp.Net Core中有如下几种类型的筛选器:

image

其中部分是内置筛选器,比如授权,响应缓存已经帮我们内置进了框架,我们只需要配置即可使用;其他筛选器是可以自定义处理逻辑的。

下图展示了筛选器类型在筛选器管道中的交互方式和执行顺序:

image

二、操作型筛选器

第一部分主要是对筛选器的一个梳理,有些重点的提炼,详情查看文档,因为文档部分理解起来比较晦涩,比如关注点是关注点,知识说筛选器可以对这些关注点启到作用,筛选器是固定的几种,不要被文档中的这种描述搞晕了,一会儿有这几种,怎么到下面又是另外几种,要注意区分重点。

操作筛选器可以实现接口IActionFilter,在接口中有两个方法,OnActionExecuting 在调用操作方法之前执行。 OnActionExecuted 在操作方法返回之后执行。

  • 先建WebAPI项目 WebAPI_Filter
  • 建一个 FilterController,并创建Get请求Test
namespace WebAPI_Filter.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class FilterController : ControllerBase
    {
        [HttpGet]
        public string Test()
        {
            return "测试Filter!";
        }
    }
}
  • 创建ActionFilter 筛选器
namespace WebAPI_Filter.Filter
{
    public class MyActionFilter : IActionFilter
    {
        public void OnActionExecuted(ActionExecutedContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl()+ "  执行之后!");
        }

        public void OnActionExecuting(ActionExecutingContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  执行之前!");
        }
    }
}
  • 在Program.cs里面添加筛选器
    image

执行测试接口
image

三、筛选器作用域和执行顺序

上面直接在Program.cs里面添加筛选器的方式称为全局筛选器,所有控制器、操作都会受全局筛选器影响。还有一种筛选器实现方式是属性筛选器,通过继承属性类然后将属性标签放置在控制器或者操作上。

新建两个属性类MyAttributeFilter 用于Controller控制器类,MyOPAttributeFilter用于操作方法上。

    public class MyAttributeFilter: ActionFilterAttribute
    {
        public override void OnActionExecuted(ActionExecutedContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  控制器之后-筛选器属性!");
        }

        public override void OnActionExecuting(ActionExecutingContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  控制器之前-筛选器属性!");
        }
    }


    public class MyOPAttributeFilter : ActionFilterAttribute
    {
        public override void OnActionExecuted(ActionExecutedContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  操作之后-筛选器属性!");
        }

        public override void OnActionExecuting(ActionExecutingContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  操作之前-筛选器属性!");
        }
    }

image

加上之前的全局筛选器,我们一共有三个作用域的筛选器,现在我们测试看看筛选器的执行顺序。
image

则可总结出不同作用域筛选器的执行顺序:

全局筛选器的 before 代码。
	控制器筛选器的 before 代码。
		操作方法筛选器的 before 代码。
		操作方法筛选器的 after 代码。
	控制器筛选器的 after 代码。
全局筛选器的 after 代码。

当然可以通过 Order 属性来确定执行顺序,在全局或者属性筛选器里面设置 Order 值,值越小执行优先级越高。

image

四、筛选器依赖注入

可按类型或实例添加筛选器。 如果添加实例,该实例将用于每个请求。

其中builder.Services.AddControllers(options => options.Filters.Add<MyActionFilter>())即为按实例添加,该MyActionFilter用于每个请求。

如果添加类型,则将激活该类型。 激活类型的筛选器意味着:第一种是为每个请求创建一个实例,第二种依赖关系注入 (DI) 将填充所有构造函数依赖项。

上面位置我们是为每个请求创建一个实例,这样的话无法使用依赖注入体系为我们自动注入,因为因为属性在应用时必须提供自己的构造函数参数,该参数需要手动指定。

比如我们想在操作方法的MyOPAttributeFilter筛选属性 注入IHostEnvironment:

    public class MyOPAttributeFilter : ActionFilterAttribute
    {
        IHostEnvironment hostEnvironment;

        public MyOPAttributeFilter(IHostEnvironment _hostEnvironment)
        {
            hostEnvironment = _hostEnvironment;
        }
        public override void OnActionExecuted(ActionExecutedContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  操作之后-筛选器属性!");
        }

        public override void OnActionExecuting(ActionExecutingContext context)
        {
            Console.WriteLine(context.HttpContext.Request.GetDisplayUrl() + "  操作之前-筛选器属性!");
            //打印环境变量
            Console.WriteLine(hostEnvironment.EnvironmentName);
        }
    }

这个时候直接就报错提示需要参数,而我们想的是通过依赖注入配置。

image

框架提供以下筛选器支持从 DI 提供的构造函数依赖项:

  • ServiceFilterAttribute
  • TypeFilterAttribute
  • 在属性上实现 IFilterFactory。

TypeFilterAttribute:不会直接从 DI 容器解析其类型。Microsoft.Extensions.DependencyInjection.ObjectFactory 对类型进行实例化,所以不需要先将MyOPAttributeFilter加入容器,直接使用:

[TypeFilter(typeof(MyOPAttributeFilter))]

image

ServiceFilterAttribute 使用需要先将MyOPAttributeFilter注入到容器,然后再使用。

image

以上就是关于AOP切面编程和筛选器的梳理,其他类型的筛选器和细节可查询官方文档:ASP.NET Core 中的筛选器

.net 温故知新【15】:Asp.Net Core WebAPI 配置 - XSpringSun - 博客园

mikel阅读(469)

来源: .net 温故知新【15】:Asp.Net Core WebAPI 配置 – XSpringSun – 博客园

关于ASP.NET Core中的配置实际之前我已经整理过.net 中以json方式进行配置的介绍(.net 温故知新:【8】.NET 中的配置从xml转向json),当时我们说ASP.NET Core也是按照基础方法,只是组织形式的问题,有个封装过程。所以我这里就着重介绍一下ASP.NET Core中配置的重点。

1、主机配置和应用程序配置

ASP.NET Core 应用配置和启动“主机”。 主机负责应用程序启动和生存期管理。 ASP.NET Core 模板创建的 WebApplicationBuilder 包含主机。 虽然可以在主机和应用程序配置提供程序中完成一些配置,但通常,只有主机必需的配置才应在主机配置中完成。

主机配置和应用程序配置是什么意思呢,可以粗略的理解为我们ASP.NET Core 项目启动的时候要用到的一些配置为主机配置,而程序运行阶段使用的配置为应用程序配置。

而ASP.NET Core 包含一些默认的主机和应用程序配置,我们先看看这些默认配置在哪里以及配置的规范。

2、默认主机配置

image

从文档描述可以看到,默认主机配置是的优先级为:

命令行-> DOTNET_ 为前缀的环境变量->ASPNETCORE_ 为前缀的环境变量

并且部分变量是锁定在启动阶段,不受其他配置的影响:

image

命令行可以通过启动程序设置,比如:dotnet run --environment Production

而其他的则可以直接设置系统环境变量,并且按照前缀优先。由于去系统设置比较麻烦,且设置后可能还需要重启VS,所以提供一些能便捷设置的能力。

launchSettings.json 仅在本地开发计算机上使用,包含配置文件设置。可以设置启动方式和相应的环境变量。

{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:21115",
      "sslPort": 44325
    }
  },
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "http://localhost:5007",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "https://localhost:7211;http://localhost:5007",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

如上是创建项目默认的launchSettings.json文件,在文件中对https、http、IIS Express等配置的ASPNETCORE_ENVIRONMENT都为Development

ENVIRONMENT 可以配置任意值,框架提供了Development、Staging、Production三种,当没有设置 DOTNET_ENVIRONMENT 和 ASPNETCORE_ENVIRONMENT 时的默认值为Production。

这就是为什么我们不在开发工具中调试,而是直接运行项目的时候会是Production。

同时我们如果要自己设置其他值,那么项目中对于使用的地方也要注意,比如appsettings.{Environment}.json文件名,这个我们稍后讲。

这个值在Program.cs中是最好的体现,当是Development时启用swagger:

image

3、默认应用程序配置

image

默认应用程序配置是的优先级为:

命令行-> 非前缀的环境变量->Development环境中用户机密配置->appsettings.{Environment}.json-> appsettings.json->主机配置(非锁定)

命令行配置和非前缀环境变量不用说了,接着就是用户机密文件,稍后我们单独说下机密文件。

然后再加载appsettings.{Environment}.json文件,这个文件是根据上面主机配置的环境变量ENVIRONMENT加载的,比如你配置ENVIRONMENT=AA,那么json文件应为appsettings.AA.json。

image

当读取了环境变量的json后就读取appsettings.json文件,该文件一般是正式部署中使用。

最后就是主机配置相关的变量,这部分优先级比较高。

(注意:这些配置的读取由配置提供程序实现,也就决定了他们不同的功能或者实现,提供程序这个概念和设计是.net 中大面积使用的,可以从这个部分去理解)

4、配置机密文件

机密管理器工具可用于存储开发环境中的机密,比如开发过程中用到的一些数据库配置,这个机密文件不在项目目录下,所以不会被上传到代码管理工具,例如git或者svn。

右键项目->管理用户机密
image

我们看到这个文件是在C盘下,而且文件夹名是一串编码,该编码在项目文件中已经自动配置好了。
image

image

5、使用配置

使用依赖注入的方式将IConfiguration注入,之后我们写一个测试获取上面我们配置的用户机密文件里面SecretKey的值。

namespace WebAPI_Config.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TestController : ControllerBase
    {
        private IConfiguration _configuration;
        public TestController(IConfiguration configuration)
        {
            _configuration = configuration;
        }


        [HttpGet]
        public string Get()
        {
            return _configuration.GetValue(typeof(string), "SecretKey").ToString();
        }
    }
}

如果对依赖注入不了解的可以看看我的另外一篇:.net 温故知新:【7】IOC控制反转,DI依赖注入

测试接口可以看到已经获取到了对应的值。
image

.net 温故知新【14】:Asp.Net Core WebAPI 缓存 - XSpringSun - 博客园

mikel阅读(427)

来源: .net 温故知新【14】:Asp.Net Core WebAPI 缓存 – XSpringSun – 博客园

一、缓存

缓存指在中间层中存储数据的行为,该行为可使后续数据检索更快。 从概念上讲,缓存是一种性能优化策略和设计考虑因素。 缓存可以显著提高应用性能,方法是提高不常更改(或检索成本高)的数据的就绪性。

二、RFC9111

在最新的缓存控制规范文件RFC9111中,详细描述了浏览器缓存和服务器缓存控制的规范,其中有一个最重要的响应报文头Cache-Control

该报文头的设置会影响我们的缓存,包括浏览器端和服务端。

RFC911:https://www.rfc-editor.org/rfc/rfc9111#name-cache-control

image

三、网页端缓存

Cache-Control中,如果设置max-age=10,则表示告诉浏览器缓存10s,而为什么浏览器要认这个表示呢,就是上面我们说的前后端都要根据RFC标准规范去实现,就是硬件的统一插口,不然其他生成出来的就用不了。

那么在ASP.NET Core 中只需要在接口上打上ResponseCacheAttribute并设置max-age的时间即可。

首先建一个ASP.NET Core WebAPI 项目,写一个获取学生的Get接口。

image

namespace WebAPI_Cache.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class CacheController : ControllerBase
    {

        public CacheController()
        {

        }

        [HttpGet]
        public ActionResult<Student> GetStudent()
        {

            return new Student()
            {
                Id = 1,
                Name = "Test",
                Age = Random.Shared.Next(0, 100),
            };
        }
    }
}
namespace WebAPI_Cache.Model
{
    public class Student
    {
        public int Id { get; set; }
        public string? Name { get; set; }
        public int Age { get; set; }
    }
}

在接口中我返回Studentage为1-100的随机数。启动项目测试,短时间内两次调用返回的age不一样

第一次age:

image

第二次age:

image

当我在接口方法打上[ResponseCache(Duration = 10)],再次调用接口返回的信息可以看到已经有了cache-control: public,max-age=10的Header。

image

并且我在10秒内的请求,只有第一次请求过服务器,其他都是从缓存中取的,查看edge浏览器网络访问如下:

image

四、服务器缓存

网页端缓存是放在浏览器端的,对于单点请求会有用,但是如果是多个不同前端请求呢。这个时候我们可以将缓存放置在后端服务中,在ASP.NET Core 中配置响应缓存中间件。

在 Program.cs中,将响应缓存中间件服务 AddResponseCaching 添加到服务集合,并配置应用,如果使用 CORS 中间件时,必须在 UseResponseCaching 之前调用 UseCors。

如果header包含 Authorization,Set-Cookie 标头,也不会缓存,因为这些用户信息缓存会引起数据混乱。

image

然后对于我们需要服务器缓存的接口打上ResponseCache属性,和设置浏览器缓存一样,还有其他参数可设置。我们通过两个进程来测试,一个用浏览器swagger,一个用postman,可以看到两个请求的age都是等于18的。所以可以确定服务器端确实存在缓存。

image

但是在用postman测试的时候记得在settings里面把Send no-cache header勾掉,如果不去掉,发送的时候就会在请求头里面包含Cache-Control:no-cache,这样服务端即便有缓存也不会使用缓存。

image

对于浏览器端相当于禁用缓存,如果禁用了缓存,发送的请求头也会带上Cache-Control:no-cache,服务端看到no-cache 后便不会再使用缓存进行响应。

而这个约定就是RFC9111的规范,所以这个后端缓存策略比较鸡肋,如果用户禁用缓存就没用了,因此我们还可以使用内存缓存。

五、内存缓存

内存缓存基于 IMemoryCache。 IMemoryCache 表示存储在 Web 服务器内存中的缓存。

  • 首先Nuget安装包
Install-Package Microsoft.Extensions.Caching.Memory
  • 在Program.cs中添加依赖
builder.Services.AddMemoryCache();
  • 缓存数据
    我添加一个Post方法模拟id查询Student

image

这样我就将数据缓存到了内存,可以设置缓存的绝对过期时间,也可以设置滑动过期,稍后我们会看到过期策略的使用。

六、缓存击穿

缓存击穿是指热点key在某个时间点过期的时候,而恰好在这个时间点对这个Key有大量的并发请求过来,或者是查询了不存在的数据,缓存里面没有,从而大量的请求打到数据库上形成数据库压力。

上面内存缓存中的写法我们可以看到,如果查询缓存等于null就会再去查询数据(我这里只是模拟,没有去写真的数据库查询),如果这样暴力请求攻击就会有问题。

对于这个问题我们可以使用ImemoryCacheGetOrCreate方法,当然它还有异步方式。通过该方法传入缓存的key和func 委托方法返回值来进行查询并缓存,如果没查询到返回的null也会存储在缓存中,防止恶意查询不存在的数据。

        [HttpPost]
        public ActionResult<Student> GetStudent2(int id)
        {
            //查询并创建缓存
            var student = _memoryCache.GetOrCreate("student_" + id, t =>
            {
                t.AbsoluteExpiration = DateTimeOffset.Now.AddSeconds(20);
                //模拟只有id=1有数据
                if (id == 1)
                {
                    return new Student()
                    {
                        Id = 1,
                        Name = "Test",
                        Age = Random.Shared.Next(0, 100),
                    };
                }
                else
                {
                    //其他的返回空,但是空值也会缓存,比如查询 id=2,id=3 都会缓存
                    return null;
                }

            });
            if (student == null)
            {
                return NotFound("未找到");
            }
            else
            {
                return student;
            }
        }

七、缓存雪崩

缓存雪崩是指缓存中数据大批量到过期时间,导致所有请求都会去查数据库,而查询数据量巨大,引起数据库压力过大甚至down机。

对于雪崩情况我们对缓存的策略主要是设置过期时间,部分不重要的站点,比如新闻网站我们将绝对过期时间AbsoluteExpiration设置的久一点。

对于要一定灵活性,能在请求不频繁的时候进行失效以更新数据的,我们可以用滑动过期时间,就是如果频繁请求就一值滑动过期时间。

当然为了避免滑动时间一直不过期,还可以两种方式混合使用。上面的例子,我们设置绝对过期时间是20秒,我们将滑动过期设置5秒,在5秒内有持续访问就一直续命,直到20秒绝对过期。

那么如果没人访问,在5秒后就过期了,这样数据下次访问也能及时查询最新数据。

image

八、分布式缓存

有了上面的缓存方案,对付一些小的简单业务系统完全够用了,但是如果你是分布式部署服务,那么像内存缓存访问的数据就是单个服务器的缓存。

你可能需要多个服务器的请求之间保持一致、在进行服务器重启和应用部署后仍然有效、不使用本地内存等情况。

这个时候我们可以使用第三方缓存,比如memecache,Redis等。Asp.Net Core 使用 IDistributedCache 接口与缓存进行交互。

  • NuGet安装包
Install-Package Microsoft.Extensions.Caching.StackExchangeRedis
  • 在 Program.cs 中注册 IDistributedCache 实现
    image

Configuration: 为连接配置。
InstanceName: 为存储键前缀。

编写测试方法GetStuden3

image

IDistributedCache 接受字符串键并以 byte[] 数组的形式添加或检索缓存项,所以数据是以byte[]形式访问,但是扩展了一个string类型的方法可以进行使用,我这里用字符串进行操作。

以上这些就是关于asp.net core 当中使用缓存的重要点和基础使用方法,详细参数和文档可参看官方文档:ASP.NET Core 中的缓存概述

.net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI - XSpringSun - 博客园

mikel阅读(404)

来源: .net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI – XSpringSun – 博客园

一、使用DI注入

在之前的文章中已经讲过DI的概念(.net 温故知新:【7】IOC控制反转,DI依赖注入),基于控制台程序演示了DI依赖注入的使用,基于Microsoft.Extensions.DependencyInjection完成。那在WebAPI中如何使用依赖注入呢?

首先新建一个WebAPI项目WebAPI_DI,框架.net 7,其实 webapi 项目也是控制台应用程序,只是在ASP.NET Core webapi框架中很多基础工作已经帮我们封装配置好了。

项目新建完成后在Program.cs 中自动生成如下代码:

namespace WebAPI_DI
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

builder.Services 则是帮我已经创建好的IServiceCollection 对象。

我们再新建一个测试类 DITestClass:

    public class DITestClass
    {
        public int Add(int i, int n)
        {
            return i + n;
        }
    }

然后我们在builder.Services中进行注册

image

最后我们在默认的WeatherForecastController控制器里面加一个post方法,并用构造函数注入的方式将DITestClass注入进去。

image

swagger中调用测试:

image

二、[FromService] 注入

FromServicesAttribute 允许将服务直接注入到操作方法,而无需使用构造函数注入。
改属性的作用主要针对我们在依赖注入初始化对象(该对象初始化很耗时),这个时候不管请求的api方法有没有用到该对象都会等待很长时间。
所以使用FromService让接口在请求的时候再注入,从而不影响其他接口

image

三、多层架构注入

在多层架构中我们如果引用了其他项目,要使用其他项目中的类,那么要在主项目中进行DI注入,这样相当于所有其他模块或者其他人写的项目都需要主项目来维护注入,比如:

新建一个ClassLibrary1项目,Class1类,方法Sub:

image

我们在web项目里面引用ClassLibrary1项目,如果要使用Class1类就需要在 Programe.cs里面注册

builder.Services.AddScoped(typeof(Class1));

image

那么有没有方法让他们自己的项目自己管理注册呢,我们可以简单改造一下

  • 新建一个类库,定义一个公共接口,安装Microsoft.Extensions.DependencyInjection 包

image

  • 在ClassLibarary1里面定义实现接口类
    public class ModulInit : IModuleInit
    {
        public void Init(IServiceCollection service)
        {
            //所有需要DI的在此处注入
            service.AddScoped<Class1>();
        }
    }
  • 在Programe.cs里面调用引用项目的注册类

image

这样其他项目也按照这种方式,在主项目中只要调用一次注册管理。不过这是最简单的方式,你也可以使用反射来查找引用的项目继承了IModuleInit的类,然后进行Init方法调用,这样会更优雅一些。
当然你还可以使用其他依赖注入框架来取代Microsoft.Extensions.DependencyInjection,也许这个问题就不再是问题!

.net 温故知新【12】:Asp.Net Core WebAPI 中的Rest风格 - XSpringSun - 博客园

mikel阅读(416)

来源: .net 温故知新【12】:Asp.Net Core WebAPI 中的Rest风格 – XSpringSun – 博客园

RPC

RPC(Remote Procedure Call),远程过程调用),这种RPC形式的API组织形态是类和方法的形式。所以API的请求往往是一个动词用来标识接口的意思,比如 https://xxxx/GetStudent?id=1 和 https://xxxx/AddStudent 这种风格,并且往往没有规范需要我们去查看接口定义文档。HTTP方法基本只用GET和POST,没有使用HTTP的其它谓词设计比较简单。

Rest

Rest:按照Http的语义来使用HTTP协议的一种风格,Rest全称Representational State Transfer(表现层状态转换)。他是一种规范或者设计风格而不是特别的技术。REST形式的API组织形态是资源和实体,请求的路由可以看出对资源的访问,规范统一接口自解释。
比如 https://xxxx/Student/1 用Get方法调用就是获取编号为1的学生。 https://xxxx/Student/1 用Delete调用就是删除编号为1的学生,用delete调用就是删除该学生。
在HTTP中这些调用方法GET、POST、PUT、PATCH、DELETE 即HTTP谓词。GET用来获取资源,POST用来新建资源,PUT用来更新指定资源,PATCH用来批量更新资源,DELETE用来删除资源,通过谓词来表示请求动作或者意图,通过url定位资源。
在请求中GET、PUT、DELETE 请求是幂等的,也就是说可以重试请求。而POST不是幂等,因为POST意思是添加数据。
在Rest风格中使用状态码来标识返回结果,其中常用200、201、400、401、404、410、500等。

ASP.NET Core WebAPI接口

ASP.NET WebAPI中我们也能看到Rest的风格,理想很丰满,显示很骨干。如果我们严格的按照Rest风格设计接口的话,需要对技术人员有很高的要求,需要去划分不同业务不同的资源定位,而且有些业务也找不到准确的谓词去定义,响应状态码有限无法表达准确的意思,或者是时间上来不及等等原因。
而且这种方式更符合国外语言表达的方式,不太适合我国宝宝体质。
所以我们在设计接口的时候不用非要用Rest风格,我们可以靠近或者在特定的更适合使用Rest接口系统中使用。
本篇我们结合Rest看下接口如何设计和交互。

  • 在http接口请求中有三种方式传递参数或者数据。
  1. URL:资源定位,也就是Rest风格,在请求的url中包含信息,比如https://xxxx/Student/1 1就是学生编号。
  2. QueryString: URL之外的额外信息,比如RPC中https://xxxx/GetStudent?id=1 id=1就是QueryString
  3. 请求报文体:供PUT、POST提交提供数据,请求体有多种格式application/x-www-form-urlencoded、multipart/form-data、application/json、text/plain、application/xml。
  • 返回状态码
    在RPC中Post请求我们习惯如果请求已经在服务器处理,不管处理结果是否正确,我们都返回200状态码。然后在返回数据中用其它信息来标识业务结果。比如{code:1,msg:"成功"}或者{code:0,msg:"失败"}
    而在Rest 中Post通常用201返回新增成功,delete 删除的数据不存在返回404,但是404大家知道可能也许是url错误,所以表诉不清。
    因此我们在实际设计中可能会进行Rest裁剪,我们既使用RPC的返回结果,同时多用准确的状态码,不用什么都返回200。
    使用RPC风格,尽量使用合理谓词,不知道使用什么谓词的时候就用POST,Get Delete参数尽量用资源定位URL,业务错误服务端返回合适的状体吗,不知道返回什么就返回400,如果请求处理成功就用200同时返回结果数据。

在上一篇中遗留的这个问题 .net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍

image

所以我们在Controller中Route配置为[Controller]则不管方法接口名称是什么,仍然以Rest的方式访问。

    [Route("[controller]")]
    [ApiController]
    public class RestCutController : ControllerBase
    {
        [HttpGet]
        public IEnumerable<string> GetStudents()
        {
            //获取所有学生
            return new string[] { "student1", "student2" };
        }

        [HttpGet("{id}")]
        public string GetStudent(int id)
        {
            //获取id的学生
            return "student"+id;
        }

        [HttpPost]
        public void PostStudent([FromBody] string value)
        {
            //新增
        }

        [HttpPut("{id}")]
        public void PutStudent(int id, [FromBody] string value)
        {
            //修改
        }

        [HttpDelete("{id}")]
        public void DeleteStudent(int id)
        {
            //删除id学生
        }
    }

image

当我们修改Rout按照RPC方式,[Route("[controller]/[action]")] 运行后发现swagger展示的接口方式就改变了。并且保留了参数URL的方式。

image

关于返回状态码的问题可以有两种方式,一种是直接在ControllerBase.Response 响应中指定返回状态码。

        [HttpDelete("{id}")]
        public string DeleteStudent(int id)
        {
            //删除id学生
            if (id == 1)
            {
                return "删除成功";
            }
            else {

                Response.StatusCode = 404;
                return "未找到!";
            }
        }

另外一种方式就是返回泛型ActionResult<string>,其中OKNotFound是继承自ActionResult然后隐式转换到泛型,也可以直接返回IActionResult或者ActionResult但是类型不确定这样swagger文档就不会解析出返回值,所以我们用ActionResult泛型。

        [HttpDelete("{id}")]
        public ActionResult<string> DeleteStudent(int id)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

        [HttpDelete("{id}")]
        public ActionResult DeleteStudent(int id) //返回ActionResult
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

最后我们在总结下关于API参数获取的方式,在[HttpGet("{id}")]中我们看到有{id},这个就是占位符,从RUL中获取,不光可以配置占位符还可以配置路径的其它值,甚至可以随意组织,只要我们的参数明和占位符相同就行。

        [HttpDelete("number/{id}/Name/{name}")] //自己组织的URL
        public ActionResult<string> DeleteStudent(int id,string name)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

当然也可以使用[FromRoute]从route获取,另外我们还有一些Attribute用于从不同的地方获取参数,比如从QueryString获取。那么我的请求URL就应该是/RestCut/DeleteStudent?id=1

        [HttpDelete]
        public ActionResult<string> DeleteStudent([FromQuery] int id)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

最后还有[FromHeader][FromForm][FromBody]这些获取参数的方式,不清楚的使用的时候查询就行了。

.net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍 - XSpringSun - 博客园

mikel阅读(497)

来源: .net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍 – XSpringSun – 博客园

ASP.NET Core 上面由于现在前后端分离已经是趋势,所以ASP.NET core MVC用的没有那么多,主要以WebApi作为学习目标。

一、创建一个WebApi项目

我使用的是VS2022, .Net 7版本。
在创建界面有几项配置:

  • 配置Https
  • 启用Docker
  • 使用控制器
  • 启用OpenAPI支持
  • 不使用顶级语句

image

其中配置Https 是WebApi是否使用https协议,启用docker是配置服务是否docker部署支持。我们这边作为学习就先不管docker了。
然后下面还有三个配置,第一个是说是否使用控制器,如果使用接口服务放在Controllers文件夹下统一管理并且相关路由规则不一样。
第二个启用OpenAPI支持,如果启用OpenAPI说的是swagger支持,也就是说.net 自动集成了swagger。
第三个不使用顶级语句,如果勾选后则程序的Program类和Main方法完整。

那么我们看下上面配置是什么意思,第二个swagger支持我们就不管了默认开启。我建两个项目AspNetCoreWebAPI_1、AspNetCoreWebAPI_2,AspNetCoreWebAPI_1我们勾选上【使用控制器】、【不使用顶级语句】。AspNetCoreWebAPI_2项目这两项都不选。

先看下项目目录结构

不同在于AspNetCoreWebAPI_1项目多了Controllers文件夹和一个WeatherForecast类,WeatherForecast类是示例接口中有使用。

image

我们再对比一下 Program

可以看到在AspNetCoreWebAPI_1项目中Program类和Main方法完整,因为要使用Controller的原因,所以依赖注入了Controller服务。并且使用了MapControllers注册路由。

在AspNetCoreWebAPI_2项目中没有只有Main方法内的代码,这就是顶级语句。然后由于我们还使用了最小API,就是不使用Controller方式注册和配置路由,直接在代码中自己注册接口和实现接口处理的代理方法。

image

按照以前asp.net习惯和项目清晰度维护性我们一般是使用Controller的方式,并且不使用顶级语句。

而最小 API,是创建具有最小依赖项的 HTTP API。 它非常适合于需要在 ASP.NET Core 中仅包括最少文件、功能和依赖项的微服务和应用。

另外还有一个appsetting.json配置文件,这部分内容也在前面已经介绍过,欢迎了解:.net 温故知新:【8】.NET 中的配置从xml转向json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

二、WebApi运行

我们调试项目AspNetCoreWebAPI_1,此时会启动一个服务在后端,同时启动浏览器访问该站点的swagger,该swagger用于调我们调试webapi接口。
image

image

我们点击示例接口WeatherForecast,访问接口会返回json格式数据。响应的headers里面可以看到后端运行的服务器是Kestrel,和我们以前.net framework不一样的事需要借助IIS作为服务器。现在的Kestrel是包含在程序中的,这个Kestrel 以后再讨论。
image

三、WeatherForecastController

WeatherForecastController是在创建项目后默认生成的一个示例Controller。在该Controller中我们可以看到几个重点项。

using Microsoft.AspNetCore.Mvc;

namespace AspNetCoreWebAPI_1.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [HttpGet(Name = "GetWeatherForecast")]
        public IEnumerable<WeatherForecast> Get()
        {
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = Summaries[Random.Shared.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}
  1. ControllerBase 基类
    web API 控制器通常应派生自 ControllerBase 而不是 Controller。 Controller 派生自 ControllerBase,并添加对视图的支持,因此它用于处理 Web 页面,而不是 Web API 请求。 如果同一控制器必须支持视图和 Web API,则派生自 Controller。
  2. [ApiController]
    [ApiController] 属性可应用于控制器类,以启用下述 API 特定的固定行为:
    1)属性路由要求:不能通过由 UseEndpoints、UseMvc 或 UseMvcWithDefaultRoute 定义的传统路由访问操作,传统路由就是以前老的路由规则,型如”{controller=Home}/{action=Index}/{id?}”。需要使用[Route(“XX”)]指定路由。
    自动 HTTP 400 响应:[ApiController] 属性使模型验证错误自动触发 HTTP 400 响应。
    2)绑定源参数推理:绑定源特性定义可找到操作参数值的位置,接口的参数通过推理规则应用于操作参数的默认数据源。
    3)Multipart/form-data 请求推理:[ApiController] 属性对 IFormFile 和 IFormFileCollection 类型的操作参数应用推理规则。 为这些类型推断 multipart/form-data 请求内容类型。
    4)、错误状态代码的问题详细信息: 将错误结果(状态代码为 400 或更高的状态码)转换为为 ProblemDetails 的结果。也就是说状态码会转换如下json格式返回信息。
{
  type: "https://tools.ietf.org/html/rfc7231#section-6.5.4",
  title: "Not Found",
  status: 404,
  traceId: "0HLHLV31KRN83:00000001"
}
  1. [Route(“[controller]”)]
    指定控制器上的属性路由,属性路由将应用的功能建模为一组资源,其中操作由 HTTP 谓词表示。也就是说路由该属性配置了路由,如上图请求时的路由https://localhost:7122/WeatherForecast,配置中“[controller]”为标记替换,为方便起见,属性路由支持标记替换,方法是将标记用方括号([、])括起来[controller]用于替换WeatherForecastController中WeatherForecast部分。
  2. [HttpGet(Name = “GetWeatherForecast”)]
    HttpGet指示Get方法为Route路由的操作,即使我们将Get方法改为其他名字仍然不影响请求路由https://localhost:7122/WeatherForecast,并且以Get方式。这种api风格即为Rest风格。Rest风格我们后面再学习。
    ASP.NET Core 具有以下 HTTP 谓词模板:

    • [HttpGet]
    • [HttpPost]
    • [HttpPut]
    • [HttpDelete]
    • [HttpHead]
    • [HttpPatch]
  3. logger日志记录
    日志记录是基础知识点,这部分内容在我们之前温故知新中已经详细介绍过,可移步了解:.net 温故知新:【9】.NET日志记录 ILogger使用和原理

以上为我们入门WebApi创建的一个默认项目,并对创建选项、项目结构、服务要点进行了分析,后面将更进一步学习分享其他asp.net core webapi重要知识。

.net 温故知新【17】:Asp.Net Core WebAPI 中间件 - XSpringSun - 博客园

mikel阅读(481)

来源: .net 温故知新【17】:Asp.Net Core WebAPI 中间件 – XSpringSun – 博客园

一、前言

到这篇文章为止,关于.NET “温故知新”系列的基础知识就完结了,从这一系列的系统回顾和再学习,对于.NET core、ASP.NET CORE又有了一个新的认识。

不光是从使用,还包括这些知识点的原理,虽然深入原理谈不上,但对于日常使用也够了,我想的是知其然,知其所以然。

在实际开发过程中可能是知道怎么使用就行,但系统学习了这些基本的框架、组件、或者说原理后,对于我们软件设计、开发、扩展和解决问题还是有帮助的。

刚好到2023新年前赶着写完,也算对自己这个系列的一个交代,实际上我平时基本不使用ASP.NET CORE,目前我主要开发桌面程序,还是用的winform。

写这个系列的初衷是想紧跟.NET的发展进程,同时储备基础知识,平时还搞一些微服务(Java)、NLP、OCR、知识图谱、前端(Vue3),只要需要反正啥都搞,没必要固执,技术只是手段,不是目的。

那么接下来就继续简单的梳理一下中间件,欢迎对这个系列拍砖!

二、中间件

中间件是一种装配到应用管道以处理请求和响应的软件。 每个组件:

  • 选择是否将请求传递到管道中的下一个组件。
  • 可在管道中的下一个组件前后执行工作。

这个是关于中间件概念的概括,官方的概括是相当精准,那么我们就围绕管道、传递、组件来看看中间件。

请求委托用于生成请求管道。 请求委托处理每个 HTTP 请求。使用 Run、Map 和 Use 扩展方法来配置请求委托。

我们照例新建一个ASP.NET CORE Web API 项目:WebAPI_Middleware

namespace WebAPI_Middleware
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

在Program.cs 中我们看到前面部分builder是配置依赖注入的东西,这部分可以参看.net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI 。

app 使用Use扩展用于中间件添加到管道中

Map 基于给定请求路径的匹配项来创建请求管道分支

Run 委托始终为终端,用于终止管道。

中间件的执行顺序过程如下:

image

三、Map

我们将上面自动创建的东西全都删除,用Map来匹配路由,然后通过不同的代理处理请求。

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();
           
            //匹配map1 请求
            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));
            //匹配map2 请求
            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));

            app.Run();
        }
    }
  • 请求map1 我们输出:map1 run

image

  • 请求map2 我们输出:map2 run

image

Asp.Net Core MapControllers 的扩展方法也是类似道理,用来匹配路由调用处理程序。

四、Run

在上面的 Map 后面我们使用的处理方法中 Run 用于终止管道。也就是说在该管道中如果调用了 Run 那么就直接返回了,即使你后面还添加了 Use 也不会执行。

app.Run(async context =>
{
    await context.Response.WriteAsync("map1 run");
});

Map 相当于是迎客进门,Map 上了就用指定的管道进行处理,如果没有 Map 上就调用主管道,也就是主管道上的其他中间件也会执行处理。比如我们再加一个 Run 用于没匹配上路由也输出点信息。

image

加了context.Response.ContentType = "text/plain; charset=utf-8"; 不然中文会乱码。

image

因为 Run 是终结点,那这个管道中我还想加其他处理怎么办呢,这个时候就该轮到 Use 出场了。

五、Use

用 Use 将多个请求委托链接在一起。 next 参数表示管道中的下一个委托。 可通过不调用 next 参数使管道短路。

首先我们在外面添加两个 Use,不放到 Map 中,这样的话就只有未匹配到的路由会调用

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();

            

            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));

            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));
            //Use1
            app.Use(async (context, next) =>
            {
                context.Response.ContentType = "text/plain; charset=utf-8";

                await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);

            });
            
            //Use2
            app.Use(async (context, next) =>
            {
                await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);

            });
            //结束管道处理
            app.Run(async context =>
            {
                await context.Response.WriteAsync("未匹配处理!\r\n", Encoding.UTF8);
            });

            app.Run();
        }
    }

最后执行的路径和最开始的图是一致的。

image

为什么将context.Response.ContentType = "text/plain; charset=utf-8"; 放到第一个 Use 呢,因为如果放到 Run 里面会报错,改变了 Header 标头。所以理论上也不要在 Use 里面发送响应WriteAsync,此处为了演示所以这么写。

image

六、中间件类

上面的代理方法可以移动到类中,这个类就是中间件类。中间件类需要如下要求:

  • 具有类型为 RequestDelegate 的参数的公共构造函数。
  • 名为 Invoke 或 InvokeAsync 的公共方法。 此方法必须:
    返回 Task。
    接受类型 HttpContext 的第一个参数。

构造函数和 Invoke/InvokeAsync 的其他参数由依赖关系注入 (DI) 填充。

将上面的未匹配路由处理逻辑移动到中间件类中:

  • TestMiddleware1:
    public class TestMiddleware1
    {
        private readonly RequestDelegate _next;

        public TestMiddleware1(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {

            context.Response.ContentType = "text/plain; charset=utf-8";

            await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • TestMiddleware2
    public class TestMiddleware2
    {
        private readonly RequestDelegate _next;

        public TestMiddleware2(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {


            await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • Program
    image
  • 运行
    image

此处的中间件使用有顺序问题,如果我先app.UseMiddleware<TestMiddleware2>() 因为 TestMiddleware1 修改了标头,根据约定是不允许的,所以程序是有报错。

image

因此中间件组件的顺序定义了针对请求调用这些组件的顺序,以及响应的相反顺序。 此顺序对于安全性、性能和功能至关重要。

七、中间件顺序

image

以上是内置中间件的默认顺序规则,具体如何使用内置中间件,可参阅官方资料。

八、写在最后

以上就是关于中间件的部分知识,结合我自己的理解做了前后衔接的梳理逻辑。

官方网站更多的是讲解每个知识点的细节,前后需要结合起来理解,当然我还是强烈建议跟着官方文档学习,而且是最权威最可信的:ASP.NET Core 中间件

这个系列历时2年,工作生活都比较忙,也有放纵啥事不相干的时候,中间断断续续的,总算是坚持完了。很多东西就是这样,累了就休息一下贵在坚持,即使再慢,积累的成果也有收获。