ASP.NET Core

0. 前言 在前一篇中我们讲到了Dapper的应用，但是给我们的感觉Dapper不像个ORM更像一个IDbConnection的扩展。是的，没错。在实际开发中我们经常用Dapper作为对EF Core的补充。当然了Dapper并不仅仅只有这些，就让我们通过这一篇文章去让Dapper更像一个ORM吧。 1. Dapper Contrib Dapper Contrib 扩展了Dapper对于实体类的CRUD方法： 安装方法： 命令行： dotnet add package Dapper.Contrib NuGet： Install-Package Dapper.Contrib 使用： using Dapper.Contrib.Extensions; 这个是一个使得Dapper功能更强大的扩展包，因为支持了CRUD，所以需要对实体类添加配置，该扩展包使用Attribute作为依据进行相关映射配置： [Table("Model")] public class Model { [Key] [ExplicitKey] public int Id{get;set;} [Computed] public int Count {get;set;} [Write] public String Name{get;set;} } 这是所有的配置，Table用来声明是一个表，必须指定表名

JWT认证简单介绍 关于Jwt的介绍网上很多，此处不在赘述，我们主要看看jwt的结构。 JWT主要由三部分组成，如下： HEADER.PAYLOAD.SIGNATURE HEADER 包含token的元数据，主要是加密算法，和签名的类型，如下面的信息，说明了 加密的对象类型是JWT，加密算法是HMAC SHA-256 {"alg":"HS256","typ":"JWT"} 然后需要通过BASE64编码后存入token中 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 Payload 主要包含一些声明信息（claim），这些声明是key-value对的数据结构。 通常如用户名，角色等信息，过期日期等，因为是未加密的，所以不建议存放敏感信息。 {"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":"admin","exp":1578645536,"iss":"webapi.cn","aud":"WebApi"} 也需要通过BASE64编码后存入token中

以ASP.NET Core WebAPI 作后端 API ，用 Vue 构建前端页面，用 Axios 从前端访问后端 API ,包括文件的上传和下载。 准备文件上传的API #region 文件上传 可以带参数 [HttpPost("upload")] public JsonResult uploadProject(IFormFile file, string userId) { if (file != null) { var fileDir = "D:\\aaa"; if (!Directory.Exists(fileDir)) { Directory.CreateDirectory(fileDir); } //文件名称 string projectFileName = file.FileName; //上传的文件的路径 string filePath = fileDir + $@"\{projectFileName}"; using (FileStream fs = System.IO.File.Create(filePath)) { file.CopyTo(fs); fs.Flush(); } return Json("ok"); }else{ return Json("no"); } } #endregion 前端vue上传组件 ( 利用Form表单上传 )

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

十年河东，十年河西，莫欺少年穷 学无止境，精益求精 ASP.NET Core 缓存Caching，.NET Core 中为我们提供了Caching 的组件。 目前Caching 组件提供了三种存储方式。 Memory Redis SqlServer 学习在ASP.NET Core 中使用Caching。 Memory Caching 1.新建一个 ASP.NET Core 项目，选择 Web 应用程序 ，将身份验证 改为 不进行身份验证。 2.添加引用 Install-Package Microsoft.Extensions.Caching.Memory 3.使用 在Startup.cs 中 ConfigureServices public void ConfigureServices(IServiceCollection services) { services.AddMemoryCache(); // Add framework services. services.AddMvc(); } 然后在控制器中依赖注入、 private IMemoryCache _cache; public LongLongController(IMemoryCache memoryCache) { _cache = memoryCache; } 1、方法：TryGetValue 及 方法缓存的存取

本文继续介绍使用Ocelot、IdentityServer4以及Spring Cloud Eureka搭建微服务网关的步骤。相关文章： 《 使用Ocelot、IdentityServer4、Spring Cloud Eureka搭建微服务网关：Step by Step（一） 》 Step 4：引入Ocelot API网关 新建一个ASP.NET Core API项目，添加对以下NuGet包的引用： Ocelot IdentityServer4 IdentityServer4.AccessTokenValidation Serilog（我使用了Serilog来输出格式化的日志，如果不使用Serilog，则不需要引用） 首先，修改Startup.cs文件，用来启用Ocelot，并指定身份认证机构为之前我们建好的IdentityServer服务： public void ConfigureServices(IServiceCollection services) { services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); services.AddAuthentication() .AddIdentityServerAuthentication("AuthProviderKey",

原文: Blazor 修仙之旅 - Ant Design of Blazor 一.前言 这是《Blazor 修仙之旅》的第三篇，前面两分别是《初次尝试》、《组件与数据绑定》，直接到这里上 Ant Design 确实连不起来，跨度比较大，其实我也是在边学边写，看的是官方文档，我觉得中间这部分重复写博客的意义不大，所以我建议去看官方文档，传送门： 点我 。如果看过我的前两篇，我建议您从这里开始看： 点我 。不用每篇都深刻理解，但需要有一个基本概念。好了，下面进入正题。 二. Ant Design of Blazor 介绍 ant-design-blazor 是国内开发者 ElderJames 创建的一个开源项目。在前不久的微软Build大会也见到了它的身影，受到了微软官方推荐，点赞！顾名思义， ant-design-blazor 是 Ant Design 的 Blazor 实现，开发和服务于企业级后台产品。 ✨ 特性 🌈 提炼自企业级中后台产品的交互语言和视觉风格。 📦 开箱即用的高质量 Razor 组件，可在多种托管方式共享。 💕 支持基于 WebAssembly 的客户端和基于 SignalR 的服务端 UI 事件交互。 🎨 支持渐进式 Web 应用（PWA） 🛡 使用 C# 构建，多范式静态语言带来高效的开发体验。 ⚙️ 基于 .NET Standard 2.1，可直接引用丰富的

原文: ASP.NET Core下载大文件的实现 当我们的ASP.NET Core网站需要支持下载大文件时，如果不做控制可能会导致用户在访问下载页面时发生无响应，使得浏览器崩溃。可以参考如下代码来避免这个问题。 关于此代码的几点说明： 将数据分成较小的部分，然后将其移动到响应输出流以供下载，从而获取这些数据。 根据下载的文件类型来指定 Response.ContentType 。（这个网址可以找到大部分文件类型的对照表： http://tool.oschina.net/commons ） 在每次调用Response.Body.Write后记得调用 Response.Body.Flush() 在循环下载的过程中使用 HttpContext.RequestAborted.IsCancellationRequested 这个判断可以帮助程序尽早发现连接是否正常。若不正常，可以及早放弃下载，以释放所占用的服务器资源。 本例使用ASP.NET Core MVC中Controller的Action来演示大文件的下载代码，根据需要也可以改为其它方式（例如ASP.NET Core的中间件）来做下载。 using Microsoft.AspNetCore.Mvc; using System.IO; using System.Web; namespace AspNetCoreDownload

根据微软官方文档的说法，有两种方法可以实现在一个app中同时适应多种不同类型的数据库，并且全部支持migrations操作。其一，使用两个dbcontext；其二，修改migration文件，添加特定数据库类型的Annotation。 本人在实际使用过程中发现，第二种情况几乎很难调通，总是在migration操作时遭遇各种奇怪问题，而且这种操作似乎也不太”干净“；第一种操作，一开始无论如何也调不通，后来发现是dbcontext的注入方式有问题，不能像默认模板生成的那样使用options参数，而是应该使用空白的构造方法，具体代码如下： DbContext： public class ApplicationDbContext : IdentityDbContext { public DbSet<Location> Locations { get ; set ; } protected override void OnModelCreating(ModelBuilder builder) { base .OnModelCreating(builder); } } public class PgDbContext : ApplicationDbContext { protected override void OnConfiguring(DbContextOptionsBuilder

原文: ASP.NET Core中的依赖注入（5）: ServiceProvider实现揭秘 【总体设计 】 本系列前面的文章我们主要以编程的角度对ASP.NET Core的依赖注入系统进行了详细的介绍，如果读者朋友们对这些内容具有深刻的理解，我相信你们已经可以正确是使用这些与依赖注入相关的API了。如果你还对这个依赖注入系统底层的实现原理具有好奇心，可以继续阅读这一节的内容。 目录 一、ServiceCallSite 二、Service 三、ServiceEntry 四、ServiceTable 五、ServiceProvider 作为DI容器的体现，ServiceProvider是ASP.NET Core依赖注入系统的一个核心对象，但是默认的实现者是一个定义在程序集 “Microsoft.Extensions.DependencyInjection.dll” 中的一个名为 “ServiceProvider” 内部（Internal）类型，而且它所依赖的很多接口和类型也是如此，所以我相信实现在这个ServiceProvider类中的服务提供机制对于绝大部分人是陌生的。本节提及的ServiceProvider不是泛指实现了IServiceProvider接口的类型，而是专指ServiceProvider这个内部类型。