在.NET Framework下有许多ORM框架,最著名的无外乎是Entity Framework,它拥有悠久的历史以及便捷的语法,在占有率上一路领先.但随着Dapper的出现,它的地位受到了威胁,本文对比了在.NET Core下 两种框架的表现以及与原生的ADO.NET 的对比. 1. Net Core下多种ORM框架特性及性能对比 1.1. Dapper是什么 1.2. 为什么选择Dapper 1.2.1. Dapper和Entity Framework Core的比较 1.3. 总结 1.

一.前言 1.本文主要内容 使用dotnet cli创建基于解决方案(sln+csproj)的项目 使用Visual Studio Code开发基于解决方案(sln+csproj)的项目 Visual Studio Code Solution插件( vscode-solution-explorer)基础使用介绍 基于 .NET Core web项目模板构建 ASP.NET Core MVC Web应用 ASP.NET Core MVC框架上手 2.本教程环境信息 软件/环境 说明 操作系统 Wi

第一部分.MVC框架内置过滤器 下图展示了Asp.Net Core MVC框架默认实现的过滤器的执行顺序: Authorization Filters:身份验证过滤器,处在整个过滤器通道的最顶层.对应的类型为: AuthorizeAttribute.cs Resource Filters:资源过滤器.因为所有的请求和响应都将经过这个过滤器,所以在这一层可以实现类似缓存的功能.对应的接口有同步和异步两个版本: IResourceFilter.cs . IAsyncResourceFilter.cs

原文:ASP.NET Core Identity 框架 - ASP.NET Core 基础教程 - 简单教程,简单编程 ASP.NET Core Identity 框架 前面我们使用了 N 多个章节,终于是把 ASP.NET Core MVC 经常使用的功能大略的过了一遍.其它的内容,要么更深入,要么更少使用,我们就不再继续了.本章节我们开始学习 ASP.NET Core 中另一个重要的框架:Identity 框架 ,也就是所谓的身份验证框架 ASP.NET Core Identity 框架用于

微软在千禧年推出 .NET战略,并在两年后推出第一个版本的.NET Framework和IDE(Visual Studio.NET 2002,后来改名为Visual Studio),如果你是一个资深的.NET程序员,相信传统的.NET应用的开发方式已经深深地烙印在你的脑子里面..NET Core带来了全新的开发体验,但开发方式的差异根本不足以成为你快速跨入.NET Core 世界的门槛,因为在.NET Core在很多方面比传统的.NET Framework应用开发要简单.为了消除很多尚未接触过.

对于一个 .NET Core开发人员,你可能没有使用过Docker,但是你不可能没有听说过Docker.Docker是Github上最受欢迎的开源项目之一,它号称要成为所有云应用的基石,并把互联网升级到下一代.Docker是dotCloud公司开源的一款产品,从其诞生那一刻算起,在短短两三年时间里就成为了开源社区最火爆的项目.对于完全拥抱开源的.NET Core来说,它自然应该对Docker提供完美的支持.对于接下来的内容,我们假设你已经对Docker有了基本的了解,并且在你的机器上(Windo

ASP.NET Core框架建立在一些核心的基础框架之上,这些基础框架包括依赖注入.文件系统.配置选项和诊断日志等.这些框架不仅仅是支撑ASP.NET Core框架的基础,我们在进行应用开发的时候同样会频繁地使用到它们.对于这里提到的这几个基础框架,依赖注入尤为重要.ASP.NET Core应用在启动以及后续针对请求的处理过程中,它会依赖各种的组件提供服务.为了便于定制,这些组件一般会以接口的形式进行“标准化”,我们将这些标准化的组件统一称为“服务(Service)”.整个ASP.NET Cor

毫不夸张地说,整个ASP.NET Core框架是建立在依赖注入框架之上的.ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器.该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务,同时也是应用程序的服务提供者,依赖注入已经成为了ASP.NET Core应用的基本编程模式. 一.服务的注册与消费 为了让读者朋友们能够更加容易地认识.NET Core提供的依赖注入框架,我在“<一个迷你版DI框架>”中特意创建了一个名为Ca

ASP.NET Core应用 具有很多读取文件的场景,比如配置文件.静态Web资源文件(比如CSS.JavaScript和图片文件等)以及MVC应用的View文件,甚至是直接编译到程序集中的内嵌资源文件.这些文件的读取都需要使用到一个IFileProvider对象.IFileProvider对象构建了一个抽象的文件系统,我们不仅可以利用它提供的统一API来读取各种类型的文件,还能及时监控目标文件的变化. 一.树形层次结构 IFileProvider对象为我们构建了一个具有层次化目录结构的文件系统

在<抽象的"文件系统">中,我们通过几个简单的实例演示从编程的角度对文件系统做了初步的体验,接下来我们继续从设计的角度来进一步认识它.这个抽象的文件系统以目录的形式来组织文件,我们可以利用它读取某个文件的内容,还可以对目录或者文件实施监控并及时得到变化的通知.由于IFileProvider对象提供了针对文件系统变换的监控功能,在.NET Core下里类似的功能大都利用一个IChangeToken对象来实现,所以我们在对IFileProvider进行深入介绍之前有必要先来了解

标题反映的是上周五一个同事咨询我的问题,我觉得这是一个很好的问题.这个问题有助于我们深入理解依赖注入框架在ASP.NET Core中的应用,以及服务实例的生命周期. 一.问题重现 我们通过一个简单的实例来模拟该同事遇到的问题.我们采用极简的方式创建了如下这个ASP.NET Core MVC应用.如下面的代码片段所示,除了注册与ASP.NET Core MVC框架相关的服务与中间件之外,我们还调用了IHostBuilder的UseDefaultServiceProvider方法将配置选项Servi

提到"配置"二字,我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中.到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中就包括定义配置的方式.总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源.我们可以采用内存的变量作为配置的数据源,也可以将配置定义在持久化的文件甚至数据库中

[接上篇]提到“配置”二字,我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中.到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中就包括定义配置的方式.总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源.我们可以采用内存的变量作为配置的数据源,也可以将配置定义在持久化的文件甚至数据库中

在<配置模型总体设计>介绍配置模型核心对象的时候,我们刻意回避了与配置同步相关的API,现在我们利用一个独立文章来专门讨论这个话题.配置的同步涉及到两个方面:第一,对原始的配置源实施监控并在其发生变化之后重新加载配置:第二,配置重新加载之后及时通知应用程序进而使应用能够及时使用最新的配置.要了解配置同步机制的实现原理,我们先得了解一下配置数据的流向. 一.配置数据流 通过前面的介绍,我们已经对配置模型有了充分的了解,处于核心地位的 IConfigurationBuilder对象借助注册的ICo

在<读取配置数据>([上篇],[下篇])上面一节中,我们通过实例的方式演示了几种典型的配置读取方式,接下来我们从设计的维度来重写认识配置模型.配置的编程模型涉及到三个核心对象,分别通过三个对应的接口(IConfiguration.IConfigurationSource和IConfigurationBuilder)来表示.如果从设计层面来审视背后的配置模型,还缺少另一个名通过IConfigurationProvider接口表示的核心对象.总的来说,配置模型由这四个核心对象组成,但是要彻底了解这

物理文件是我们最常用到的原始配置载体,而最佳的配置文件格式主要有三种,它们分别是JSON.XML和INI,对应的配置源类型分别是JsonConfigurationSource.XmlConfigurationSource和IniConfigurationSource,它们具有如下一个相同的基类FileConfigurationSource. 一.FileConfigurationSource FileConfigurationSource总是利用一个IFileProvider对象来读取配置文件,

.NET Core采用的这个全新的配置模型的一个主要的特点就是对多种不同配置源的支持.我们可以将内存变量.命令行参数.环境变量和物理文件作为原始配置数据的来源.如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML.JSON和INI等).如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义IConfigurationSource的方式将其他形式数据作为配置来源. 一.MemoryConfigurationSource 在之前的实例演示都在使用MemoryConfigu

虽然应用程序可以直接利用通过IConfigurationBuilder对象创建的IConfiguration对象来提取配置数据,但是我们更倾向于将其转换成一个POCO对象,以面向对象的方式来使用配置,我们将这个转换过程称为配置绑定.配置绑定可以通过如下几个针对IConfiguration的扩展方法来实现,这些扩展方法都定义在NuGet包"Microsoft.Extensions.Configuration.Binder"中. 一.ConfigurationBinder public s

生命周期决定了IServiceProvider对象采用怎样的方式提供和释放服务实例.虽然不同版本的依赖注入框架针对服务实例的生命周期管理采用了不同的实现,但总的来说原理还是类似的.在我们提供的依赖注入框架Cat中,我们已经模拟了三种生命周期模式的实现原理,接下来我们结合“服务范围”的概念来对这个话题做进一步讲述. 一.服务范围(Service Scope) 对于依赖注入框架采用的三种生命周期模式(Singleton.Scoped和Transient)来说,Singleton和Transient都

一个物理文件可以直接作为资源内嵌到编译生成的程序集中.借助于EmbeddedFileProvider,我们可以采用统一的编程方式来读取内嵌的资源文件,该类型定义在 "Microsoft.Extensions.FileProviders.Embedded"这个NuGet包中.在正式介绍EmbeddedFileProvider之前,我们必须知道如何将一个项目文件作为资源内嵌入到编译生成的程序集中. 一.将项目文件变成内嵌资源 在默认情况下,我们添加到一个.NET Core项目中的静态文件并

ASP.NET Core应用中使用得最多的还是具体的物理文件,比如配置文件.View文件以及作为Web资源的静态文件.物理文件系统由定义在NuGet包"Microsoft.Extensions.FileProviders.Physical"中的PhysicalFileProvider来构建.我们知道System.IO命名空间下定义了一整套针操作物理目录和文件的API,实际上PhysicalFileProvider最终也是通过调用这些API来完成相关的IO操作. public class