ASP.NET Core

本篇内容属于非实用性（拿来即用）介绍，如对框架设计没兴趣的朋友，请略过。 快一个月没有写博文了，最近忙着两件事; 一：阅读刘墉先生的《说话的魅力》，以一种微妙的，你我大家都会经常遇见的事物，来建议说话的“艺术和魅力”，对于我们从事软件开发、不太善于沟通和表达的朋友来说，也算是一项软技能了，推荐喜欢阅读的朋友有时间阅读，给你不一样的阅读体验。 二：编写基于Net Core的Rpc框架。之前有朋友说如何将Rpc等整个体系集成到dotnet框架中，我想这篇博文会给你一个答案。 哦，对了，我不建议直接将代码直接复制下来然后去运行的朋友，因为这样你达不到学习的目的，也违背了笔者的初衷。谢谢理解。 一：简单回顾一下之前的介绍 继续贴上之前的一张图片 根据上面图，服务化原理可以分为3步： 服务端启动并且向注册中心发送服务信息，注册中心收到后会定时监控服务状态（常见心跳检测）； 客户端需要开始调用服务的时候，首先去注册中心获取服务信息； 客户端创建远程调用连接，连接后服务端返回处理信息； 　　第3步又可以细分，下面说说远程过程调用的原理： 目标：客户端怎么调用远程机器上的公开方法 服务发现，向注册中心获取服务(这里需要做的有很多：拿到多个服务时需要做负载均衡，同机房过滤、版本过滤、服务路由过滤、统一网关等)； 客户端发起调用，将需要调用的服务、方法、参数进行组装； 序列化编码组装的消息

最近在做一个基于Azure云的物联网分析项目： .netcore采集程序向Azure事件中心(EventHubs)发送数据，通过Azure EventHubs Capture转储到Azure BlogStorage，供数据科学团队分析。 为什么使用Azure事件中心？ Azure事件中心是一种Azure上完全托管的实时数据摄取服务， 每秒可流式传输来自website、app、device任何源的数百万个事件。提供的统一流式处理平台和时间保留缓冲区，将事件生成者和事件使用者分开。 事件生成者： 可使用https、AQMP协议发布事件 分区：事件中心通过 分区使用者模式 提供消息流式处理功能，提高可用性和并行化 事件接收者：所有事件中心使用者通过AMQP 1.0会话进行连接，读取数据 例如，如果事件中心具有四个分区，并且其中一个分区要在负载均衡操作中从一台服务器移动到另一台服务器，则仍可以通过其他三个分区进行发送和接收。 此外，具有更多分区可以让更多并发读取器处理数据，从而提高聚合吞吐量。 了解分布式系统中分区和排序的意义是解决方案设计的重要方面。 为了帮助说明排序与可用性之间的权衡，请参阅 CAP 定理 最直观的方式：请在portal.azure.cn门户站点---->创建事件中心命名空间---> 创建事件中心 .NetCore 准实时批量发送数据到事件中心 .NET库 (Azure

0. 前言 在《asp.net core 系列》之前的几篇文章中，我们简单了解了路由、控制器以及视图的关系以及静态资源的引入，让我们对于asp.net core mvc项目有了基本的认识。不过，这些并不是 asp.net core mvc项目的全部内容，剩下的内容我将结合实战项目为大家讲解其中的知识。现在，就让我们开始吧。 1. 项目构建 抛开之前的项目，现在跟着我重新创建一个项目，第一步依旧是先创建一个解决方案： dotnet new sln --name Template 我先介绍一下这个项目（指整个项目，不是单独的asp.net core 应用），这是一个后台管理的模板应用，提供了常见后台系统（管理员端）的功能，包括员工管理、部门管理、角色管理等功能。 现在回到项目中，通常一个项目需要一个模型层，一个数据提供层以及web展示层。然后，我们依次创建 Data、Domain、Web 三个项目，其中Data和Domain 是 classlib，Web是mvc项目。 # 确保当前目录与 Template.sln 处于相同的目录 dotnet new classlib --name Data dotnet new classlib --name Domain dotnet new mvc --name Web 添加三个项目到解决方案中： dotnet sln add Data

前言 在上篇文章[ ASP.NET Core中的响应压缩 ]中我们谈到了在ASP.NET Core服务端处理关于响应压缩的请求，服务端的主要工作就是根据Content-Encoding头信息判断采用哪种方式压缩并返回。之前在群里有人问道过，现在的网络带宽这么高了还有必要在服务端针对请求进行压缩吗？确实，如今分布式和负载均衡技术这么成熟，很多需要处理高并发大数据的场景都可以通过增加服务器节点来进行。但是，在资源受限的情况下，或者是还没必要为了某一个点去增加新的服务器节点的时候，我们还是要采用一些程序本身的常规处理手段来进行处理。笔者个人认为响应压缩的使用场景是这样的，在带宽压力比较紧张的情况，且CPU资源比较充足的情况下，使用响应压缩整体效果还是比较明显的。 有压缩就有解压，而解压的工作就是在请求客户端处理的。比如浏览器，这是我们最常用的Http客户端，许多浏览器都是默认在我们发出请求的时候(比如我们浏览网页的时候)在Request Head中添加Content-Encoding，然后根据响应信息处理相关解压。这些都源于浏览器已经内置了关于请求压缩和解压的机制。类似的还有许多，比如常用的代理抓包工具Filder也是内置这种机制的。只不过需要手动去处理，但实现方式都是一样的。有时候我们在自己写程序的过程中也需要使用这种机制，在传统的.Net HttpWebRequest类库中

2020/01/29, ASP.NET Core 3.1, VS2019 摘要：基于ASP.NET Core 3.1 WebApi搭建后端多层网站架构【8.3-编写角色业务的增删改】 编写最简单的增删改业务，涉及到DI依赖注入的使用、AutoMapper的使用、工作单元与仓储的使用、雪花Id的生成 文章目录 此分支项目代码 本章节介绍了编写最简单的增删改查业务，涉及到DI依赖注入的使用、AutoMapper的使用、工作单元与仓储的使用 类库添加引用 向 MS.Services 类库添加对 MS.Models 项目的引用 BaseService 在 MS.Services 类库中添加 BaseService.cs 类： using AutoMapper; using MS.Common.IDCode; using MS.DbContexts; using MS.UnitOfWork; namespace MS.Services { public interface IBaseService { } public class BaseService : IBaseService { public readonly IUnitOfWork<MSDbContext> _unitOfWork; public readonly IMapper _mapper; public readonly

AutoMapper 简介 AutoMapper是一个对象映射器，它可以将一种类型的对象转换为另一种类型的对象。 它提供了映射规则及操作方法，使我们不用过多配置就可以映射两个类, 可以帮我们免于编写无聊的映射代码. 在代码层与层之间隔离模型model上非常有用. AutoMapper 使用 初始化 创建两个简单的类用于测试: public class UserEntity { public int Id { get; set; } public string Name { get; set; } } public class UserDTO { public int Id { get; set; } public string Name { get; set; } } AutoMapper可以使用静态类和实例方法来创建映射. 静态类方式 Mapper.Initialize(cfg => cfg.CreateMap<UserEntity, UserDTO>()); var userDTO = Mapper.Map<UserDTO>(user); 实例方式 var config = new MapperConfiguration(cfg => cfg.CreateMap<UserEntity, UserDTO>()); var mapper = config.CreateMapper(

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

NuGet添加 NLog.Web.AspNetCore 。 <PackageReference Include="Microsoft.AspNetCore.App" /> 添加配置文件 新建一个文件nlog.config(建议全部小写，linux系统中要注意)， 并右键点击其属性，将其“复制到输出目录”设置为“始终复制”。文件内容如下 <?xml version="1.0" encoding="utf-8" ?> <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true"> <targets> <target xsi:type="File" name="allfile" keepFileOpen="false" encoding="utf-8" fileName="${basedir}/logs/${shortdate}-${level}.log" layout="${longdate}|${event-properties:item=EventId_Id}|${uppercase:${level}}|${logger}|${message} ${exception:format

当出现 The CORS protocol does not allow specifying a wildcard (any) origin and credentials at the same time. Configure the CORS policy by listing individual origins if credentials needs to be supported 跨域错误的时候 只需要给予一个可信列表即可。修改内容如下： services.AddCors(options => options.AddPolicy( " CorsPolicy " , builder => { builder.WithOrigins( new string [] { " http://127.0.0.1:5500 " }) .AllowAnyMethod() .AllowAnyHeader() .AllowCredentials(); })); 如果真的就不想做任何限制，其实也是有办法的。只需要将 AllowAnyOrigin 替换为 SetIsOriginAllowed(_ => true) 就可以解决。 services.AddCors(options => options.AddPolicy( " CorsPolicy " , builder => {

Entity Framework Core配置DbContext的两种方式 ​ 使用Entity Framework 迁移过程 中遇到过一个问题，在这里拿出来晒晒。 Unable to create an object of type 'xxxContext'. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728 ​ 要解决这个问题，就是我下面要阐述的内容了。 1. DbContext的两种配置方式 ​ 我们先来看看DbContext的两个构造函数： protected DbContext(); public DbContext([NotNullAttribute] DbContextOptions options); ​ 还有DbContext的两个重写方法： protected internal virtual void OnConfiguring(DbContextOptionsBuilder optionsBuilder); protected internal virtual void OnModelCreating(ModelBuilder modelBuilder); ​ 根据错误提示，在微软的官方文档中