ASP.NET Core

说到ASP.NET CORE 管道模型不得不先来看看之前的ASP.NET 的管道模型，两者差异很大，.NET CORE 3.1 后完全重新设计了框架的底层，.net core 3.1 的管道模型更加灵活便捷,可做到热插拔，通过管道可以随意注册自己想要的服务或者第三方服务插件. ASP.NET 管道 请求进入ASP.NET 工作进程后，由进程创建HttpWorkRequest 对象，封装此次请求有关的所有信息，然后进入HttpRuntime 类进行进一步的处理。HttpRuntime 通过请求信息创建HttpContext 上下文对象，此对象将贯穿整个管道，直到响应结束。同时创建或从应用程序池里初始化一个HttpApplication对象，由此对象开始处理之前注册的多个HttpModule。之后调用HandlerFactory 创建Handler处理程序，最终处理此次请求内容，生存响应返回。 以前的管道模型是全家桶方式，所有的管道不支持热插拔，一次性全部集成在里面，所有这也是ASP.NET 没有.NET CORE 性能好的一大原因所在。 IHttpModule 和IHttpHandler 已经不复存在了，取而代之的是一个个中间件（Middleware）。Server将接收到的请求直接向后传递，依次经过每一个中间件进行处理，然后由最后一个中间件处理并生成响应内容后回传

升级到 Asp.Net Core 2.0 (2017/08/29 更新) 为什么使用 Jwt 最近，移动开发的劲头越来越足，学校搞的各种比赛都需要用手机 APP 来撑场面，所以，作为写后端的，很有必要改进一下以往的基于 Session 的身份认证方式了，理由如下： 移动端经常要保持长时间（1 到 2 星期）在线，但是 Session 却不好在服务端保存这么久，虽然可以持久化到数据库，但是还是挺费资源 移动端往往不是使用的网页技术，所以藏在 Cookie 里面的 SessionId 不是很方便的传递给服务端 服务端暴露给客户端的接口往往是 RESTful 风格的，这是一种无状态的 API 风格，所以身份认证的方式最好也是无状态的才好 所以我选择了使用 Jwt (Json Web Token) 这个技术。Jwt 是一种无状态的分布式的身份验证方式，与 Session 相反，Jwt 将用户信息存放在 Token 的 payload 字段保存在客户端，通过 RSA 加密的方式，保证数据不会被篡改，验证数据有效性。 下面是一个使用 Jwt 的系统的身份验证流程： 可以看出，用户的信息保存在 Token 中，而 Token 分布在用户的设备中，所以服务端不再需要在内存中保存用户信息了 身份认证的 Token 传递时以一种相当简单的格式保存在 header 中，方便客户端对其进行操作 Jwt

asp.net core很大的方便了跨平台的开发者，linux的开发者可以使用apache和nginx来做反向代理，windows上可以用IIS进行反向代理。 反向代理可以提供很多特性，固然很好。但是还有复杂性，我们也可以使用windows service来直接启动kestrel。 asp.net core官方网站提供了一种基于windows服务部署的方法: 在 Windows 服务中托管 ASP.NET Core 这种方式需要修改代码，然后部署的时候，使用命令行创建、安装服务，然后再启动。 感觉还是不够爽快，我们可以使用topshelf改造一下。 TopShelf topshelf可以很便捷地将一个windows console程序改造成windows service，只需要稍微修改一下代码结构，然后通过nuget包就可以简单操作了。安装与部署也是 极其 方便，而且，topshelf在调试的时候，直接是作为console程序，极其便于调试。 TopShelf项目地址： http://topshelf-project.com/ 步骤 首先引用nuget包： Install-Package TopShelf 然后改造一下program.cs public class Program { public static void Main(string[] args) { var rc =

标题：从零开始实现ASP.NET Core MVC的插件式开发(八) - Razor视图相关问题及解决方案 作者：Lamond Lu 地址： https://www.cnblogs.com/lwqlun/p/13197683.html 源代码： https://github.com/lamondlu/Mystique 前景回顾 从零开始实现ASP.NET Core MVC的插件式开发(一) - 使用Application Part动态加载控制器和视图 从零开始实现ASP.NET Core MVC的插件式开发(二) - 如何创建项目模板 从零开始实现ASP.NET Core MVC的插件式开发(三) - 如何在运行时启用组件 从零开始实现ASP.NET Core MVC的插件式开发(四) - 插件安装 从零开始实现ASP.NET Core MVC的插件式开发(五) - 使用AssemblyLoadContext实现插件的升级和删除 从零开始实现ASP.NET Core MVC的插件式开发(六) - 如何加载插件引用 从零开始实现ASP.NET Core MVC的插件式开发(七) - 近期问题汇总及部分解决方案 简介 在上一篇中，我给大家分享了程序调试问题的解决方案以及如何实现插件中的消息传递，完稿之后，又收到了不少问题反馈，其中最严重的问题应该就是运行时编译Razor视图失败的问题。

0. 前言 在上一篇，我们搭建了一个项目框架，基本上是一个完整的项目。目前而言，大部分的应用基本都是这个结构。好的，不废话了，进入今天的议题：完成并实现数据层的基础实现。 1. 数据实体 通常情况下，一个项目的数据实体中字段并不是完全没有规律可寻。通常情况下，必须有一个主键。有些时候，会要求在数据表中增加上次修改时间和创建时间，以及创建人和修改人的主键。 所以，我们可以创建一个泛型父类，来帮我们定义这些公共字段： using System; namespace Data.Infrastructure { public class BaseEntity<T> { public T Id { get; set; } public string ModifyUserId { get; set; } public DateTime? ModifyTime { get; set; } public string CreatorId { get; set; } public DateTime? CreateTime { get; set; } } } 看上述代码里，命名空间并不在Data里，而是在Data.Infrastructure里。这个命名空间 Infrastructure 用来存放一些项目的架构类或者接口，里面还会其他的类。 那么，给这个类补充一些可能有用的方法： public

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

1.Startup.cs中添加下面的代码 // 设置接收文件长度的最大值。 services.Configure<FormOptions>(x => { x.ValueLengthLimit = int .MaxValue; x.MultipartBodyLengthLimit = int .MaxValue; x.MultipartHeadersLengthLimit = int .MaxValue; }); 2.请求的Action 加上下面的代码 RequestSizeLimit 是传入一个表示字节的数字来对请求的大小进行限制，另一个 DisableRequestSizeLimit 的意思就是不限制了 // [RequestSizeLimit()] [DisableRequestSizeLimit] public async Task<IActionResult> Post() {.......} 来源： oschina 链接： https://my.oschina.net/u/4274413/blog/4273230

前言 　 　不管是前端，还是后端，做数据合法性验证是避免不了的，这边文章就记录一下Asp.NetCore3.1 WebApi中的模型验证； 传统写法--不使用模型验证 　　 来，先上图： 　　 我相信，应该绝大多数人都这样写过，反正我是，现在有时候也写，不是说这样不行, 根据业务场景进行评估，看是否合适； 这里就那用户维护新增举个例；如上图， 判断参数合法性一堆，这显得这个接口方法比较臃肿； 　　使用模型验证 　　 先上图 　　首先在参数模型上打上注解 　　 　　 接口方法优化 　　 　　 如上图，是不是看着这个方法比较清晰了，没那么臃肿了，代码量似乎也就减少了，出Bug的概率是不是也降低了，哈哈； 　　调用结果，我这里什么都没传，返回400及校验消息(消息可以自定义) 　　如上图，当参数都为空时，在没进Action之前就被拦截了，并且返回400和校验的错误消息， 这是.NetCore自动校验了，我们可以将其关闭，让访问到Action中来，如下： 　　 　　 在运行进行API调用，同样传递不合法参数，这下就会走到Action中了，如下： 　　 显然，通过这样的方式，可以管控到验证结果，并根据验证结果返回对应信息，但是，这样会需要在每个控制器中需要验证的Action方法中进行判断和处理，这无疑使得代码的复用性不好，写重复的代码，所以我们需要自己控制模型验证结果

现在 dotnet 的服务创建十分具有效率，本文的前提要求是电脑上面已经安装了 dotnet 程序，接下来就是三句命令行的事情 如果还没有安装 dotnet 那么请到 https://dotnet.microsoft.com/ 官网 下载安装，基本上看界面就知道如何下载安装 接下来在可以进行测试的临时文件夹打开命令行，这一句话不算在本文的命令行数量统计内 第一句话创建一个 web 服务程序的代码到 Foo 文件夹 dotnet new webapi -o Foo 这里的 new 就是创建的意思，而 webapi 指的是创建的是什么样的模板的代码，后续加上的 -o 表示创建到哪个文件夹，这里指定创建到 Foo 文件夹里面 第二句话就是进入 Foo 文件夹 cd Foo 第三句话就是运行刚才创建的代码，第一次运行编译 dotnet 项目需要等待一下依赖包的下载 dotnet run 此时就完成了一个简单的服务的创建和运行了，如果看到下面代码表示服务已经运行起来，可以访问 info: Microsoft.Hosting.Lifetime[0] Now listening on: https://localhost:5001 info: Microsoft.Hosting.Lifetime[0] Now listening on: http://localhost:5000 info:

原文: 【无私分享：ASP.NET CORE 项目实战（第二章）】添加EF上下文对象，添加接口、实现类以及无处不在的依赖注入（DI） 目录索引 　 【无私分享：ASP.NET CORE 项目实战】目录索引 简介 　　 上一章，我们介绍了安装和新建控制器、视图，这一章我们来创建个数据模型，并且添加接口和实现类。 添加EF上下文对象 　　 按照我们以前的习惯，我们还是新建几个文件夹 　　Commons：存放帮助类 　　Domians：数据模型 　　Services：接口和实现类 　　 我们在Domains文件夹下添加一个类库 Domain 我们新建一个类 ApplicationDbContext 继承 DbContext 1 using Microsoft.EntityFrameworkCore; 2 3 namespace Domain 4 { 5 public class ApplicationDbContext : DbContext 6 { 7 public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) 8 : base (options) 9 { 10 } 11 12 protected override void OnModelCreating(ModelBuilder