.NET Core

上一篇我们介绍了数据塑形，HATEOAS和内容协商，并在制器方法中完成了对应功能的添加；本章我们将介绍日志和测试相关的概念，并添加对应的功能 一、全局日志 在第一章介绍项目结构时，有提到.NET Core启动时默认加载了日志服务，且在appsetting.json文件配置了一些日志的设置，根据设置的日志等级的不同可以进行不同级别的信息的显示，但它无法做到输出固定格式的log信息至本地磁盘或是数据库，所以需要我们自己手动实现，而我们可以借助日志框架实现。 ps：在第7章节中我们记录的是数据处理层方法调用的日志信息，这里记录的则是ASP.NET Core WebAPI层级的日志信息，两者有所差异 1、引入日志框架 .NET程序中常用的日志框架有log4net，serilog 和Nlog，这里我们使用Serilog来实现相关功能，在BlogSystem.Core层使用NuGet安装 Serilog.AspNetCore ，同时还需要搜索 Serilog.Skins 安装希望支持的功能，这里我们希望添加对文件和控制台的输出，所以选择安装的是 Serilog.Skins.File和Serilog.Skins.Console 需要注意的是Serilog是不受appsetting.json的日志设置影响的，且它可以根据命名空间重写记录级别。还有一点需要注意的是

0. 前言 不知道有没有动手能力强的小伙伴照着上一篇的内容写过程序呢？如果有的话，应该会在使用的时候发现以下几个问题： 每次启动都需要经过漫长的时间去遍历磁盘里的文件目录 因为数据是用的字典保存的，所以会消耗大量的内存空间 不能多次查询 现在我们就针对这些问题，让我们的小工具实用起来。 1. 分析与实现 在动手之前，我们先分析一下问题。在实际开发之前，无论是接到什么需求都要先仔细分析一下，确定好方案再动手方为开发的正道。嗯，没毛病。因为开发过程中跟产品对线、跟客户对线要占整个项目的一半左右时间。好了，不废话了。继续： 遍历文件目录的时间过长，那么我们是不是可以用异步并发去遍历呢？ 数据用字典保存会消耗内存空间，那么我们是不是可以用其他的方式保存呢？ 不能多次查询，是不是可以使用循环，然后设置一个退出条件？ 1.1 C#的异步/并发实现 在C#里，异步和并发的实现是依据线程、任务来实现的。在之前《C# 基础知识系列- 12 任务和多线程》里大概介绍了一下线程和任务，我们知道线程本身是没法返回数据的，它与主线程进行数据交互的过程十分需要注意线程安全。而任务可以返回数据，不需要像线程一样小心翼翼地与主线程进行数据交互。任务有一个优点，它比线程更轻量，所以在当前环境下我们可以试试任务。 当然，线程也有优点，那就是线程的运行环境相对更封闭一点，它能完成一个长的大型运算。 那么继续上一篇的内容

最近GRPC很火，感觉整RPC不用GRPC都快跟不上时髦了。 gRPC设计 gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统，自然而然就盯上了它，但是它真能够解决所有问题吗？不见得，先看看他的优点： gRPC的主要优点： 现代高性能轻量级 RPC 框架。 协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。 可用于多种语言的工具，以生成强类型服务器和客户端。 支持客户端、服务器和双向流式处理调用。 使用 Protobuf 二进制序列化减少对网络的使用。 对应的适用场景： 微服务 ：gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。 点对点实时通信 ：gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。 多语言环境 ：gRPC 工具支持所有常用的开发语言，因此，gRPC 是多语言环境的理想选择。 网络受限环境 ：gRPC 消息使用 Protobuf（一种轻量级消息格式）进行序列化。 gRPC 消息始终小于等效的 JSON 消息。 gRPC还是有缺点的： 浏览器支持受限 ：绝大数浏览器不支持 HTTP/2 非人工可读取 ：proto文件规定的格式在通讯中会序列化成二进制数据，人工解析较为困难。 不适用的场景与替代： 浏览器可访问的API ：gRPC

C# 数据操作系列 - 19 FreeSql 入坑介绍 前言 前几天FreeSql的作者向我推荐了FreeSql框架，想让我帮忙写个文章介绍一下。嗯，想不到我也能带个货了。哈哈，开个玩笑～看了下觉得设计的挺有意思的，所以就谢了这篇文章。 简单介绍一下，FreeSql 是NCC组织的沙盒级项目，是一款功能强大的 ORM 组件，支持 .NET Core、.NET Framework 和 Xamarin。目前 FreeSql 支持以下数据库：MySQL、PostgreSQL、SqlServer、Oracle、Sqlite、Odbc、微软 Access 以及国产数据库达梦。 也就是说也是一个由国内优秀开发者维护的优秀项目，初步看了下功能很齐全。小伙伴们有时间可以取瞅瞅。下图是我从它GitHub仓库里复制过来的。可以看见支持的功能还是相当多的。 关于NCC社区，是.net core的一个开源社区，也是国内最大的.net core开源社区 初步使用 照例，没安装就没有调用。所以，在创建项目之后，安装一下吧： dotnet add package FreeSql 然后创建一个IFreeSql对象： public class FreeSqlContext { public static IFreeSql FreeSqlConnect { get; } = new FreeSql

目录 简介 功能依赖 消息摘要算法 MD算法 家族发展史 应用场景 代码实现 MD5 示例代码 SHA算法 应用场景 代码实现 SHA1 SHA256 示例代码 MAC算法 HMAC算法的典型应用 HMAC算法的安全性 HMAC组合散列函数 代码实现 HMAC-MD5 HMAC-SHA1 HMAC-SHA256 示例代码 数字签名算法 Rivest-Shamir Adelman算法（ RSA） 代码实现 SHA1WithRSA SHA256WithRSA 示例代码 数字签名算法（DSA） 代码实现 SHA1/DSA SHA256/DSA 示例代码 椭圆曲线数字签名算法（ECDSA） 代码实现 SHA1/ECDSA SHA256/ECDSA 示例代码 下期预告 简介 加解密现状，编写此系列文章的背景： 需要考虑系统环境兼容性问题（Linux、Windows） 语言互通问题（如C#、Java等）（加解密本质上没有语言之分，所以原则上不存在互通性问题） 网上资料版本不一、或不全面 .NET官方库密码算法提供不全面，很难针对其他语言（Java）进行适配 本系列文章主要介绍如何在 .NET Core 中使用非对称加密算法、编码算法、消息摘要算法、签名算法、对称加密算法、国密算法等一系列算法，如有错误之处，还请大家批评指正。 本系列文章旨在引导大家能快速、轻松的了解接入加解密

前言 有些时候我们会发现方法名称都正确匹配，但就是找不到对应请求接口，所以本文我们来深入了解下何时会出现接口请求404的情况。 匹配控制器Action方法（404） 首先我们创建一个web api应用程序，我们给出如下示例控制器代码 [ApiController] [Route( " [controller]/[action] " )] public class WeatherController : ControllerBase { [HttpGet] string Get() { return " Hello World " ; } } 当我们进行如上请求时会发现接口请求不到，这是为何呢？细心的你应该可能发现了，对于请求方法是私有，而不是公共的，当我们加上public就可以请求到了接口 [HttpGet( " get " )] public string Get() { return " Hello World " ; } 匹配控制器Action方法本质 经过如上示例，那么对于Action方法的到底要满足怎样的定义才能够不至于请求不到呢？接下来我们看看源码怎么讲。我们找到DefaultApplicationModelProvider类，在此类中有一个OnProvidersExecuting方法用来构建控制器和Action方法模型，当我们构建完毕所有满足条件的控制器模型后

原文: ASP.NET Core Authentication and Authorization 最近把一个Asp .net core 2.0的项目迁移到Asp .net core 3.1，项目启动的时候直接报错: InvalidOperationException : Endpoint CoreAuthorization .Controllers .HomeController .Index ( CoreAuthorization ) contains authorization metadata , but a middleware was not found that supports authorization . Configure your application startup by adding app .UseAuthorization () inside the call to Configure (..) in the application startup code . The call to app .UseAuthorization () must appear between app .UseRouting () and app .UseEndpoints (...). Microsoft .AspNetCore .Routing

在.Net Core 中使用ActionFilterAttribute重写OnResultExecuting来实现对返回接口自定义输出： 1、创建 ResultFilter ，继承自 ActionFilterAttribute public class ResultFilter : ActionFilterAttribute { /// <summary> /// 接口返回前验证 /// </summary> /// <param name="context"></param> public override void OnResultExecuting(ResultExecutingContext context) { if (context.Result is ObjectResult) { var objectResult = context.Result as ObjectResult; if (objectResult.StatusCode == 203) { context.Result = new ObjectResult(new { code = objectResult.StatusCode, msg = new { ip = $"{context.HttpContext.Connection.RemoteIpAddress}", info =

前言 磁盘怎么又满了？赶紧 快 打电话给运维扩容扩容扩容！这个问题已经是我入职新公司两个月来，第 3 次听到了。经过一通了解，事情原来是这样的。虽然我们使用了阿里云的 OSS 对象存储服务，但是为了不暴露 AccessKeyId 以及 AccessKeySecret 给客户端，所以全部是由客户端上传到我们的服务器，由我们服务器中转上传，其实只要上传完成删除相应的文件应该就不会引发磁盘空间不足的问题，奈何之前的精神小伙并没有干这一步，文件放磁盘上当备份用。由此引发思考中转上传是不是太麻烦了，直传 OSS 不香吗? 如何保证 AccessKeyId 以及 AccessKeySecret 的安全以及 Bucket 权限问题呢？这就是下面要讲的阿里云 OSS 上的 Sts 授权模式。 STS 临时授权访问 OSS OSS 可以通过阿里云 STS（Security Token Service）进行临时授权访问。通过 STS，您可以为第三方应用或子用户（即用户身份由您自己管理的用户）颁发一个自定义时效和权限的访问凭证。 以上是官方原话，经过我的实践结合理论，可以得出：我们可以通过 STS 颁发一个临时的 AccessKeyId , AccessKeySecret , SecurityToken , 用户可以通过这3个访问凭证对 Oss 进行相应操作。在我们申请颁布访问凭证的时候

算法面试题：一个List ，要求删除里面的男生，不用Linq和Lamda，求各种解，并说明优缺点！ 解题思路 这是群里某位小伙伴去面试碰到的面试题，从题目本身来看，面试官应该是要考察面试者对泛型 List 的理解程度，也算是对基础的理解。这里面还是有很多需要考察的知识点，没关系，我们走一步看一步。 首先，题目没有限定数量，我们知道，只谈毒性不谈剂量的都是耍流氓，那我们就假定要处理的数据有 10000 条好了。 数据准备好了 static readonly string text =