zyq025的专栏

.NET内功心法

容易忘，赶紧记录下来~~~

这个解析用着感觉不错哦

别慌，名词都是搞来吓人的~~~

缓存用起来真香

用起来真舒服~~~

细节很重要~~~

SignalR 让Web实时通信更简单

前言系统分布式已经成为程序员的家常，将大型单体划分为相对简单的小模块，分散系统能力，提升系统扩展性、功能模块复用性等；各功能模块之间肯定会有很多数据共享和交互的应用场景，那就避免不了各模块之间的通信；目前用的比较多的方式是HTTP（Restful API）接口、消息队列等，而HTTP（Restful API）接口应该是目前应用比较广泛的，相对之前的webservice和WCF都显得比较轻量级，而且实用；随着微服务的盛行，对服务间的通信要求也越来越高，比如传输方式、传输速率、传输内容大小等，而HTTP

前言关于HttpClient的使用，个人在很多场景都派上用场了，比如在Winform或后台服务中用其调用接口获取和上传数据、微服务中用其进行各服务之间的数据共享等，到目前来看，似乎还没有出现过什么问题，但当我看到官方文档介绍使用方式时，再回顾之前项目的代码，只能说没出问题比较庆幸。官方文档介绍的大概意思如下：HttpClient类使用比较简单，但在某些情况下，许多开发人员却并未正确使用该类；虽然此类实现 IDisposable，但在 using 语句中声明和实例化它并非首选操作，因为释放 Ht

前言上一篇在聊MemoryCache的时候，用到了Autofac提供的拦截器进行面向切面编程，很明显能体会到其优势，既然涉及到了，那就趁热打铁，一起来探探面向切面编程。正文1. 概述在软件业，AOP为Aspect Oriented Programming的缩写，意为：面向切面编程，通过预编译方式和运行期间动态代理实现程序功能统一维护的一种技术。AOP是OOP(面向对象程序设计)的延续，是软件开发中的一个热点，是函数式编程的一种衍生范型。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务

前言是这么一回事：我正在苦思一个业务逻辑，捋着我还剩不多的秀发，一时陷入冥想中......突然聊天图标一顿猛闪，打开一看，有同事语音；大概意思是：同事把项目中Redis部分缓存换成MemoryCache/Memcached，还强调MemoryCache/Memcached的效率是Redis的2~5倍；当时我想到的是Memcached，听到的似乎也是，心想：怎么可能，就算有性能差，也不至于那么多；因为当时同事代码还没提交，然后就陷入讨论ing，最后还是没聊通，我就跑到同事那当面沟通(要去打架吗

前言好东西要分享，之前一直在使用wkhtmltopdf进行pdf文件的生成，常用的方式就是先安装wkhtmltopdf，然后在程序中用命令的方式将对应的html生成pdf文件，简单而且方便；但重复的编码使得想在wkhtmltopdf基础上进行封装，偶然间发现有小伙伴已经封装的还不错啦，常用的功能都已经实现，源码地址：https://github.com/fpanaccia/Wkhtmltopdf.NetCore。作者将其打包成Nuget包(Wkhtmltopdf.NetCore)，直接引入使用即可；

前言还记得当初学习数据库操作时，用ADO.NET一步一步地进行数据操作及查询，对于查询到的数据还得对其进行解析，然后封装返回给应用层；遇到这种重复而繁琐的工作，总有一些大神或团队对其进行封装，从而出现了很多ORM框架，让小伙伴把更多精力放在业务处理上，同时更多的面向程序对象开发，对工作效率的提升有很大的帮助。目前关于C#出现了很多ORM框架，比较流行的大概有FreeSql (国内)、SqlSugar (国内)、Dapper (国外)、EF/EF Core (国外)、linq2db (国外)等，当

前言随着微服务的流行，而DDD(领域驱动设计)也光速般兴起，CRQS(Command Query Responsibility Seperation--命令查询职责分离)、领域事件名词是不是经常在耳边环绕，而MediatR组件经常用来对其技术的落地，凭这，小伙伴们说火不火?(强行引入主题，牛掰不！！！)；但是今天不说微服务，也不说DDD，只说MediatR的使用，哈哈哈，开始吧；正文二话不说就上图，图中大概意思就是说：MediatR是用.Net实现的简单中介者模式...

前言MVC过滤器在之前http://Asp.Net的时候就已经广泛使用啦，不管是面试还是工作，总有一个考点或是需求涉及到，可以毫不疑问的说，这个技术点是非常重要的； 在之前参与的面试中，得知很多小伙伴只知道有一两个过滤器，而对其执行顺序了解的还是很模糊，少部分小伙伴甚至还没有使用过。这里就详细来说说这块的内容。正文来，直接上菜，然后再慢慢品；在Asp.NetCore 中，MVC有以下五种过滤器，根据执行顺序的不同，用于不同场景：上图中大概的流程如下：用户发...

前言权限管控对于一个系统来说是非常重要的，最熟悉不过的是菜单权限和数据权限，上一节通过Jwt实现了认证，接下来用它实现接口权限的验证，为什么不是菜单权限呢？对于前后端分离而言，称其为接口权限感觉比较符合场景(我是这么理解的)；数据权限牵涉到具体业务，这里就不说啦！正文对于一些比较简单的系统，访问角色可能只有固定的几种，比如一些产品管理系统，通常只有管理员、维护员、用户三种权限，管理员拥有整个系统的权限，维护员只能访问产品维护相关页面和操作，用户只能访问产品的一些信息，如果类似这种情况，可以.

前言撸码需谨慎，裸奔有风险。经常在一些技术交流群中了解到，还有很多小伙伴的项目中Api接口没有做任何安全机制验证，直接就裸奔了，对于一些临时项目或是个人小项目还好，其余的话，建议小伙伴们酌情考虑都加上，毕竟接口安全这事可大可小。通常会采用session、cookie、jwt、ids4等方式进行接口安全认证或授权，这里就先拿jwt说事，ids4知识点比较多，后续单独整理整理；对于session和cookie的方式就留给小伙伴们研究吧，因为最近接触或是和朋友聊到的项目中，使用的不多，所以就不单独拿出来细

前言随着前后端分离开发模式的流行，接口对接、联调成为常事，前端同事会经常问：我需要调哪个接口？这个接口数据格式是啥？条件都传啥？ 对于一些紧急接口可能会采取沟通对接，然后补文档，其他的都会回一句：看文档。 那难道要一边开发一边写文档吗？早些年是这样的，但对于后端同事就很不自在了，代码敲的正起劲，突然又要去写文档(不然前端同事会时刻催或是来沟通)，这样效率显然不是很高。而Swagger就能很舒服的解决问题(当然也有其他方式，挑一个比较火的)，用Swagger大概会有以下好处：良好的可视化界面，在线查看

前言路由，这词绝对不陌生，不管在前端还是后端都经常提到，而这节不说其他，就聊.NetCore的路由；在之前的http://Asp.NetMVC 中，路由算是面试时必问的考点，可见其重要性，它的主要作用是映射URL，而不需要关注服务器的物理文件结构，提高安全性，同时规范了URL请求，有利于搜索引擎优化；所以在Asp.NetCore中当然也不能缺少，以下说说其应用。正文在Asp.NetCore中，注册路由方式有两种：模板路由注册：适合应用于MVC页面项目，相对于来说，使用模板的形式更加方便，约.

前言如今前后端分离开发模式如火如荼，开发职责更加分明（当然前后端一起搞的模式也没有完全褪去）；而对于每个公司产品实施来说，部署模式会稍有差别，有的会单独将前端文件部署为一个站点，有的会将前端文件和后端站点整合一起部署；通常当项目规模比较大的时候，分开站点部署是不错的选择，管理和维护清晰，而对于一些小型项目，整合在一起部署为一个站点就显得相对比较方便，毕竟有时候开发是你、部署是你、维护也是你；如果选择整合部署，或者是项目包含静态文件(如图片)的访问，接下来的内容就有用武之地了~~~正文Asp.

前言在开发过程中，肯定避免不了读取文件操作，比如读取配置文件、上传和下载文件、Web中html、js、css、图片等静态资源的访问；在配置文件读取章节中有说到，针对不同配置源数据读取由对应的IConfigurationProvider进行读取，其实读取文件也是一样，针对于不同类型(物理文件、嵌入文件、云端文件等)文件，就由对应的IFileProvider的实现进行读取，下面详细说说；正文由于通过IFileProvider将目录文件进行抽象化，统一规范读取操作，使得读取不同地方的文件就显得更加方便

前言Asp.NetCore中的请求管道是通过一系列的中间件组成的，使得请求会根据需求进行对应的过滤和加工处理。在平时开发中会时常引用别人定义好的中间件，只需简单进行app.Usexxx就能完成中间件的注册，但是对于一些定制化需求还得自己进行处理和封装，以下说说中间件的注册应用和自定义中间件；正文在上一小节中有简单提到，当注册第三方封装的中间件时，其实本质还是调用了IApplicationBuilder的Use方法；而在开发过程中，会使用以下三种方式进行中间件的注册：Use：通过Use的方式注

前言中间件(Middleware)对于Asp.NetCore项目来说，不能说重要，而是不能缺少，因为Asp.NetCore的请求管道就是通过一系列的中间件组成的；在服务器接收到请求之后，请求会经过请求管道进行相关的过滤或处理；正文那中间件是那路大神？会经常听说，需要注册一下中间件，如图：所以说，中间件是针对请求进行某种功能需求封装的组件，而这个组件可以控制是否继续执行下一个中间件；如上图中的app.UserStaticFiles()就是注册静态文件处理的中间件，在请求管道..

前言上一节对日志的部分核心类型进行简单的剖析，相信现在再使用日志的时候，应该大概知道怎么一回事了，比如记录器是怎么来的，是如何将日志内容写入到不同目的地的等；当然还有很多细节没深入讲解，抽时间小伙伴们可以去研究研究；废话不多说，接下来主要举例演示日志作用域及第三方日志框架的扩展；正文说到日志作用域，相信很多小伙伴听着不是那么熟悉吧，之前进行日志记录时候，是不是把内容记录下来就完事了，最多就是再稍微格式化一下；如果是这样，那在排查问题的时候肯定差不多是这样：一点一点的扒日志，然后根据关键词找大概地

前言鲁迅都说：没有日志的系统不能上线(鲁迅说：这句我没说过，但是在理)！日志对于一个系统而言，特别重要，不管是用于事务审计，还是用于系统排错，还是用于安全追踪.....都扮演了很重要的角色；之前有很多第三方的日志框架也很给力，如Log4Net、NLog和Serilog等，在.NetCore中也集成了日志模型，使用便捷，同时很方便的与第三方日志框架进行集成扩展；正文实例演示之前，先了解一下日志级别，后续如果不想输出全部日志，可以通过日志级别进行过滤，同时通过日志级别可以标注日志内容的重要程度：

前言来啦！来啦！上一节一堆代码，是不是感觉甚是无味啊？没关系，这里结合上一节内容专注举例演示，绝不废话！走起~~~~~正文老规矩，一个WebApi项目走起，项目结构如下：上一节中提到，Options是基于依赖注入的，所以我们需要将相关服务进行注册，如下：注册完成之后就可以直接用啦，这里新建了一个ComputerController进行测试：运行走起：通常在使用的时候，相关服务的配置会放到配置文件中，比如数据库连接字符...

前言.NetCore中提供的选项框架，我把其理解为配置组，主要是将服务中可供配置的项提取出来，封装成一个类型；从而服务可根据应用场景进行相关配置项的设置来满足需求，其中使用了依赖注入的形式，使得更加简单、便捷；另外和配置(Configuration)系统的无缝结合，使得服务更加灵活；而对于Options我们经常在注册服务中用到，相信只要接触过.NetCore中的小伙伴都知道，在注册服务的时候，经常在参数中进行Options的配置(如下图)，可以直接的说：没有Options的服务不是好服务~~~.

前言通常程序中配置少不了，配置的修改也避免不了，配置的热更新为此给应用程序带来很大的便捷，不用重启，提高用户体验；但往往有时候需要对修改进行审计，也就是需要记录，有时候也会针对配置修改的时候触发相关操作，比如说发邮件通知，或是其他业务操作等，遇到这种情况，配置变更监听的用处就体现出来了，接下来就尝尝鲜去；正文在看前两篇文档的小伙伴可能会看到IConfiguration、IConfigurationProvider接口中有一个GetReloadToken()方法，之前只是注释了一下，其实此方法返回

前言上一篇针对不同的配置源进行举例演示，感受到不同配置源和不同数据格式使用统一操作的便捷(即没有什么加一层解决不了的，这个不是我说的)，这里接着说说自定义配置源、配置热更新、配置绑定对象相关操作；配置源回顾：命令行 环境变量 文件(Json、ini、Xml)正文自定义配置源可能会有疑问，内置的配置源那么多，还不够用吗？只能这么说，需求各种各样，说不一定有一些定制需求 ；就像如今微服务时代，针对于每个服务各自解析配置信息，显得就不那么合适了，所以就会有一个配置中心的存在，而这里的配置

前言配置对于程序来说，绝对是必不可少，毕竟配置是应用或组件动态适应各种环境的最优方案，没有之一(我还年轻，我是这么认为的)；之前可能用的最多的配置源是命令行、文件(XML、Json、INI)，Web中对于Asp.Net程序员Web.Config是接触的再多不过了，不管怎样，读取配置信息是避免不了啦，但是对于各种配置源不同及格式不同，又得专门开发对应的配置解析程序；不慌，.NetCore内置的配置框架为此一解烦恼，开箱即用，正文详解，走起~~~正文体验之前，简单聊聊有关配置的几个核心类型及其对应的

前言前两节针对.NetCore自带的依赖注入进行简要概述，对于日常开发的需求应该是能满足了，那为什么还需要引入第三方依赖注入组件呢，这里就从自带的依赖注入来分析，有什么样的需求满足不了？主要归纳为以下几点：属性注入：自带的依赖注入不支持属性注入方式，而现阶段开发，属性开发模式应该在程序中无处不在了； 按名称注入：自带的依赖注入不支持名称注入，当注入多个同接口的不同实现时，要获取指定类型的对象不太方便，但通过名称可以方便获取； 注册方式：自带的依赖注入需要指定具体类型，这样每增加一个新类型就要添加

前言上一小节简单阐述了依赖注入及Asp.NetCore中自带依赖注入组件的常规用法，其中提到容器管控了自己创建对象的生命周期，包含了三种生命周期：Singleton、Scoped、Transient， 对于Singleton、Transient相对于Scoped来说比较好理解，其实这里面有一个作用域的概念，也可以理解为根容器和子容器的范围；上一小节中有一个例子中说到，当注入的生命周期为Scoped的时，在同一个请求内，注入的对象都是同一个，这里Asp.NetCore将每个请求作为了一个作用域，在此作用域

前言现阶段而言，依赖注入相关组件如果不会用一两个，感觉在Code的世界里肯定是落伍了，最起码得有工厂模式的思想，知道这样做的好处；提及到依赖注入，通常会关联出两个概念：Ioc(控制反转)和DI(依赖注入)控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体将其所依赖的

前言一个Asp.NetCore项目，知道大概的启动流程是有必要的，比如后续遇见配置信息覆盖等相关问题时也大概知道是什么原因，了解原因之后，再去搜索引擎找答案，否则目标不明确，茫茫人海怎么会一下找到自己想要的，除非是“偶遇”；“偶遇”太难，一起浅析一个Asp.NetCore 项目的启动流程；正文先创建一个WebAPI项目，用的是.NetCore3.1，后续的项目例子都统一用.NetCore3.1,除非特殊说明；项目如下：如上图所示，一个WebAPI项目启动方式本质也是一个控制台程序，程序入

前言随着.NetCore版本发布变更，在最近一年左右开始接触到.NetCore，之前只是传闻，并没有动手实操；.NetCore逐渐成熟，大大小小的公司也开始进行使用，感觉再不学习就落后了，于是乎搜索各种资料开始学习，学习路径是通过官网、博客、视频；总的来说，项目开发应该没有问题，但是总觉得所学知识不够体系，总是停留在会用阶段，对于相关联知识也不熟，从而导致好多零碎的知识点每次都只能通过搜索引擎解决，浪费了不少时间，而且对于微服务体系的架构也需要有扎实的知识，所以痛定思痛，从头整理，将知识点形成体系。初篇