.NetCore中的Middleware是装配到管道处理请求和响应的组件:每个组件都可以决定是否继续进入下一个管道.并且可以在进入下一个管道前后执行逻辑: 最后一个管道或者中断管道的中间件叫终端中间件: 1.创建中间件管道IApplicationBuilder app.Run()拦截请求后中断请求,多个Run()只执行第一个: app.Run(async httpcontenxt => { httpcontenxt.Response.ContentType = "text/plain; c

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

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

这节演示一下自定义中间件,第一节我们讲到,中间件的处理流程就像一个俄罗斯套娃,那这种俄罗斯套娃型的流程内部是如何实现的呢,下面请看代码​. ​第一种写法是直接写在Configure方法中的,使用app.Use(委托)配合lambda表达式使用,适合很轻量级的中间件.​ app.Use(async (context, next) => { await context.Response.WriteAsync("CustomerMiddleWare1-in\n"); await nex

前言 FreeSql 目前版本号 0.5.5,预计明年元旦发布 1.0.0,切莫小看了版本号,目前单元测试方法1350+,并且每个方法内的涵盖面又比较广(不信的话见下图),每一次版本发布都作了较多的测试工作. 最近的一段时间,关注我们的人时不时会看见扩展包发布,今天振奋人心的功能主要是核心部分实现(扩展包今天当配角).就不多啰嗦了,咱们直接入主题. 功能一:MapType 类型映射 使用 codefirst 时序列化 json 或 jsonb 数据类型报错 使用 postgresql + ef

前言 这是一篇纯技术干货的分享文章,FreeSql 已经基本完成 .NETCore 最方便的 ORM 使命,我们正在筹备生态的建立,比如 ABP 中如何使用 FreeSql 的实现,需要各种各样的扩展包,好多好多工作量.有没有大神愿意无偿参与做这件事情,好吧..应该没有人!! 大约是在三天前,因为使用 FreeSql 的某项目需要做一个简单的后台功能,以便录入或管理数据.在实施的过程中好怀念当初 dotnetGen 生成器的味道,用它产生 curd 基本功能几乎是秒做: 然后今天发表的 Free

Java Spring Boot VS .NetCore (一)来一个简单的 Hello World Java Spring Boot VS .NetCore (二)实现一个过滤器Filter Java Spring Boot VS .NetCore (三)Ioc容器处理 Java Spring Boot VS .NetCore (四)数据库操作 Spring Data JPA vs EFCore Java Spring Boot VS .NetCore (五)MyBatis vs EFCore

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

[.NET Core项目实战-统一认证平台]开篇及目录索引 这篇文章,我们将从Ocelot的中间件源码分析,目前Ocelot已经实现那些功能,还有那些功能在我们实际项目中暂时还未实现,如果我们要使用这些功能,应该如何改造等方面来说明. 一.Ocelot源码解读 在使用一个组件前,最好我们要了解其中的一些原理,否则在使用过程中遇到问题,也无从下手,今天我带着大家一起来解读下Ocelot源码,并梳理出具体实现的原理和流程,便于我们根据需求扩展应用. Ocelot源码地址[https://github

前言 FreeSql 发布至今已经有9个月,功能渐渐完善,自身的生态也逐步形成,早在几个月前写过一篇文章<ORM 开发环境之利器:MVC 中间件 FreeSql.AdminLTE>,您可以先阅读上一篇文章内容了解来龙去脉,再回到这里观看. 我个人非常喜欢小规模团队的＂单打独斗＂,有的时候即使在大公司,也是做着3-5个人团队的小项目,相信不少人有类似的经历. 从上一篇文章可以看出,早先的 FreeSql.AdminLTE 只不过是花瓶,应用场景非常有限,仅仅在开发环境时管理测试数据的用途,这之后

前言 FreeSql 发布至今已经有9个月,功能渐渐完善,自身的生态也逐步形成,早在几个月前写过一篇文章<ORM 开发环境之利器:MVC 中间件 FreeSql.AdminLTE>,您可以先阅读上一篇文章内容了解来龙去脉,再回到这里观看. 我个人非常喜欢小规模团队的＂单打独斗＂,有的时候即使在大公司,也是做着3-5个人团队的小项目,相信不少人有类似的经历. 从上一篇文章可以看出,早先的 FreeSql.AdminLTE 只不过是花瓶,应用场景非常有限,仅仅在开发环境时管理测试数据的用途,这之后

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

简介 前几天发表了<基于Yarp实现内网http穿透>,当时刚刚从原理图变成了粗糙的代码实现,项目连名字都还没有,也没有开放源代码.在之后几天的时间,我不断地重构,朝着"可集成.可二次开发"的要求来完善项目,并项目取名为HttpMouse,象征着穿越能力很强的老鼠,同时把代码开源在Github/HttpMouse上. 原理 开发库 HttpMouse以库的形式提供给开发者,让开发者可以构建符合自身业务的http内网穿透系统.相比提供编译好的二进制可执行文件,库的方式更灵活,

前言介绍 喜欢小规模团队的＂单打独斗＂,有的时候即使在大公司,也经常做着3-5个人团队的小项目,相信很多人有类似的经历. 本文介绍如何将项目中已存在的[实体类],直接生产出 CRUD 后台管理界面. 对于通用后台管理系统的生成,除了单纯的对单表 crud 操作外,我还喜欢利用导航属性的操作,比如: 1.Song.Tag 多对多场景,添加/更新 Song 时可以把 Tag 一起保存: 2.列表页,希望外键.多对多出现在过滤筛选条件: 3.列表页,希望枚举出现在过滤筛选条件: 4.删除时,级联删除所

.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含有界面的组件包 (三)构建界面 .NetCore 下开发独立的(RPL)含有界面的组件包 (四)授权过滤 .NetCore 下开发独立的(RPL)含有界面的组件包 (五)授权过滤参数处 理 .NetCore 下开发独立的(RPL)含有界面的组件包 (六)实现业务功能 在.netcore中大家经常会看

你是否会迷惑当我们请求一个ASP.NetWeb应用程序以后,它是怎么处理这些请求的,后台是怎么工作的,今天就讲一下Asp.NetCore Web应用程序中的请求处理过程. 上一节,我们讲到,Startup文件中用来配置中间件(middleware),这个中间件就是用来处理请求的.那标题中的请求管道又是什么呢,其实所有的中间件就组成了一个请求管道,我们的请求,到达ASP.NetWeb应用程序,就会被送到第一个中间件中,一个个的访问,每个中间件都对请求进行处理,直到进行到最后一个中间件原路返回处理结

项目中想通过统一的接口格式返回异常信息,而不是404 500等HTTP协议层的异常响应 例如 { , , "message":"用户名或密码不正确", "detail":"", "data":null } 我们需要引用一个异常处理中间件,ExceptionHandlerMiddleWare 代码如下 using GeduData.Server; using GeduService.Resp; using M

ASP.NET Core 中间件 目录: 什么是中间件 ? IApplicationBuilder 使用 IApplicationBuilder 创建中间件 Run.Map 与 Use 方法 实战中间件 参考原文 我们知道在 ASP.NET 中,有一个面向切面的请求管道,由22个主要的事件构成,能够让我们在往预定的执行顺序里面添加自己的处理逻辑.一般采取两种方式:一种是直接在 Global.asax 中对应的方法中直接添加代码.一种是是在 web.config 中通过注册 HttpModule

using System; using System.IO; namespace WebApi.Restful.Middlewares { public class MemoryWrappedHttpResponseStream : MemoryStream { private Stream _innerStream; public MemoryWrappedHttpResponseStream(Stream innerStream) { this._innerStream = innerStr

缘起 哈喽,老张的不定期更新的日常又开始了,在咱们的前后端分离的.net core 框架中,虽然已经实现了权限验证<框架之五 || Swagger的使用 3.3 JWT权限验证[修改]>,只不过还是有一些遗留问题,最近有不少的小伙伴发现了这样的一些问题,本来想着直接就在原文修改,但是发现可能怕有的小伙伴看不到,就单发一条推送吧,所以我还是单写出一篇文章来说明解决这些问题,希望对无论是正在开发权限管理系统,还是平时需要数据库动态绑定权限分配的你有一些启发和思考.今天咱们注意解决这三个问题: 1.

在实际业务系统中,当单个数据库不能承载负载压力的时候,一般我们采用数据库读写分离的方式来分担数据库负载.主库承担写以及事务操作,从库承担读操作. 为了支持多种数据库我们先定义一个数据类型字典.key为连接字符串,value为数据库类型: /// <summary> /// 数据库方言集合 /// </summary> private readonly Dictionary<string, DatabaseDialectEnum> DialectDictionary =