共17页: 上一页 1 2 3 4 5 6 7 8 9 下一页 末页 
摘要: HostingEnvironment是承载应用当前执行环境的描述,它是对所有实现了IHostingEnvironment接口的所有类型以及对应对象的统称。HostingEnvironment类型是对IHostingEnvironment接口的默认实现。对于通过HostingEnvironment的四个属性(ApplicationName、EnvironmentName、WebRootPath和ContentRootPath) 承载的四个与执行环境相关的设置,在WebHostOptions对象上都具有对应的属性,后者是前者的数据来源。由于WebHostOptions对象是WebHostBuilder根据它采用的配置来创建的,所以这些设置最初来源于使用的配置。阅读全文
posted @ 2016-12-06 08:34 Artech 阅读(4371) 评论(5) 编辑
摘要: 在《历数依赖注入的N种玩法》演示系统自动注册服务的实例中,我们会发现输出的列表包含两个特殊的服务,它们的对应的服务接口分别是IApplicationLifetime和IHostingEnvironment,我们将分别实现这两个接口的服务统称在ApplicationLifetime和HostingEnvironment。我们从其命名即可以看出ApplicationLifetime与应用的声明周期有关,而HostingEnvironment则用来表示当前的执行环境,本篇文章我们着重来了解ApplicationLifetime与整个AASP.NET Core应用的生命周期有何关系.阅读全文
posted @ 2016-12-05 08:37 Artech 阅读(2759) 评论(3) 编辑
摘要: 日志记录不仅对于我们开发的应用,还是对于ASP.NET Core框架功能都是一项非常重要的功能特性。我们知道ASP.NET Core使用的是一个极具扩展性的日志系统,该系统由Logger、LoggerFactory和LoggerProvider这三个核心对象组成。我们可以通过简单的配置实现对LoggerFactory的定制,以及对LoggerProvider添加。阅读全文
posted @ 2016-11-28 07:10 Artech 阅读(2311) 评论(2) 编辑
摘要: 在对ASP.NET Core管道中关于依赖注入的两个核心对象(ServiceCollection和ServiceProvider)有了足够的认识之后,我们将关注的目光转移到编程层面。在ASP.NET Core应用中基于依赖注入的编程主要涉及到两个方面,它们分别是将服务注册到ServiceCollection中,和采用注入的方式利用ServiceProvider提供我们所需的服务。阅读全文
posted @ 2016-11-25 07:00 Artech 阅读(2261) 评论(4) 编辑
摘要: 我们一致在说 ASP.NET Core广泛地使用到了依赖注入,通过前面两个系列的介绍,相信读者朋友已经体会到了这一点。由于前面两章已经涵盖了依赖注入在管道构建过程中以及管道在处理请求过程的应用,但是内容相对分散和零碎,我们有必要针对这个主题作一个归纳性的介绍。采用依赖注入的服务均由某个ServiceProvider来提供,但是在ASP.NET Core管道涉及到两个不同的ServiceProvider,其中一个是在管道成功构建后创建并绑定到WebHost上的ServiceProvider,对应着WebHost的Services属性。另一个ServiceProvider则是在管道处理每个请求时即时创建的,它绑定当表示当前请求上下文上,对应着HttpContext的RequestServices属性,两个ServiceProvider之间存在着父子关系。阅读全文
posted @ 2016-11-24 07:05 Artech 阅读(5799) 评论(5) 编辑
摘要: 注册的服务器和中间件共同构成了ASP.NET Core用于处理请求的管道, 这样一个管道是在我们启动作为应用宿主的WebHost时构建出来的。要深刻了解这个管道是如何被构建出来的,我们就必须对WebHost和它的创建者WebHostBuilder这个重要的对象具有深刻的理解。[阅读全文
posted @ 2016-11-23 08:45 Artech 阅读(2110) 评论(2) 编辑
摘要: 中间件的注册除了可以借助Startup对象(DelegateStartup或者ConventionBasedStartup)来完成之外,也可以利用另一个叫做StartupFilter的对象来实现。所谓的StartupFilter是对所有实现了IStartupFilter接口的类型及其对象的统称。阅读全文
posted @ 2016-11-22 07:13 Artech 阅读(1898) 评论(4) 编辑
摘要: 跨程序集之间的类型转移帮助框架或者类库的提供者解决这样的难题:某个类型在框架1.0版本的时候定义在程序集A中,当升级到2.0的时候被转移到了程序集B中,使用旧版本的应用可以在不做任何修改的情况下直接对使用的升级后的框架程序集阅读全文
posted @ 2016-11-21 15:20 Artech 阅读(858) 评论(3) 编辑
摘要: 一个ASP.NET Core应用被启动之后就具有了针对请求的处理能力,而这个能力是由管道赋予的,所以应用的启动同时意味着管道的成功构建。由于管道是由注册的服务器和若干中间件构成的,所以应用启动过程中一个核心的工作就是完成中间节的注册。由于依赖注入在ASP.NET Core应用这得到非常广泛的应用,框架绝大部分的工作都会分配给我们预先注册的服务,所以服务注册也是启动WebHost过程的另一项核心工作。这两项在启动过程中必须完成的核心工作通过一个名为Startup的对象来承载。阅读全文
posted @ 2016-11-17 08:36 Artech 阅读(2916) 评论(9) 编辑
摘要: 我们在《服务器在管道中的“龙头”地位》中对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了介绍,为了让读者朋友们对管道中的服务器具有更加深刻的认识,接下来我们采用实例演示的形式创建一个自定义的服务器。这个自定义的服务器直接利用HttpListener来完成针对请求的监听、接收和响应,我们将其命名为HttpListenerServer。阅读全文
posted @ 2016-11-16 08:02 Artech 阅读(2245) 评论(7) 编辑
摘要: ASP.NET Core管道由注册的服务器和一系列中间件构成。我们在上一篇中深入剖析了中间件,现在我们来了解一下服务器。服务器是ASP .NET Core管道的第一个节点,它负责完整请求的监听和接收,最终对请求的响应同样也由它完成。服务器是我们对所有实现了IServer接口的所有类型以及对应对象的统称。阅读全文
posted @ 2016-11-15 08:16 Artech 阅读(2175) 评论(6) 编辑
摘要: ASP.NET Core管道虽然在结构组成上显得非常简单,但是在具体实现上却涉及到太多的对象,所以我们在 “通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程”(上篇、中篇、下篇) 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在本系列 中,我们会还原构建模拟管道时可以舍弃和改写的部分,向读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个服务器与一组有序排列的中间件构成,前者仅仅完成请求监听、接收和响应这些与底层网络相关的工作,至于请求接收之后和响应之前的所有工作都交给中间件来完成。阅读全文
posted @ 2016-11-14 08:35 Artech 阅读(4262) 评论(12) 编辑
摘要: 论是JavaScript还是C#程序,我们已经习惯了采用“链式调用”的方式进行编程,这样确实会使我们的程序变得很精练。采用这种链式调用方式的很多方式都是扩展方法。我们在定义这种扩展方法的时候,有一个地方值得我们注意。阅读全文
posted @ 2016-10-26 14:48 Artech 阅读(3206) 评论(7) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-13 23:01 Artech 阅读(2586) 评论(6) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-12 22:53 Artech 阅读(3323) 评论(9) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-11 22:52 Artech 阅读(4267) 评论(3) 编辑
摘要: FileProvider构建了一个抽象文件系统,作为它的两个具体实现,PhysicalFileProvider和EmbeddedFileProvider则分别为我们构建了一个物理文件系统和程序集内嵌文件系统。总的来说,它们针对的都是“本地”文件,接下来我们通过自定义FileProvider构建一个“远程”文件系统,我们可以将它视为一个只读的“云盘”。由于文件系统的目录结构和文件内容都是通过HTTP请求的方式读取的,所以我们将这个自定义的FileProvider命名为HttpFileProvider。阅读全文
posted @ 2016-09-29 08:38 Artech 阅读(3418) 评论(5) 编辑
摘要: 这是今天作项目支持的发现的一个关于WCF的问题,虽然最终我只是添加了一行代码就解决了这个问题,但是整个纠错过程是痛苦的,甚至最终发现这个问题都具有偶然性。具体来说,这是一个关于如何自动为服务接口(契约)的每个操作添加FaultContract与WCF服务元数据发布的问题。接下来通过一个简单的实例来说明这个因为少写了一行代码引发的血案。阅读全文
posted @ 2016-09-21 14:43 Artech 阅读(4795) 评论(13) 编辑
摘要: ETW是Event Tracing for Windows的简称,它是Windows提供的原生的事件跟踪日志系统。由于采用内核(Kernel)层面的缓冲和日志记录机制,所以ETW提供了一种非常高效的事件跟踪日志解决方案。阅读全文
posted @ 2016-09-14 08:23 Artech 阅读(3868) 评论(1) 编辑
摘要: 从微软推出第一个版本的.NET Framework的时候,就在“System.Diagnostics”命名空间中提供了Debug和Trace两个类帮助我们完成针对调试和跟踪信息的日志记录。在.NET Framework 2.0中,微软引入了TraceSource并对跟踪日志系统进行了优化,优化后的跟踪日志系统在.NET Core中又经过了相应的简化。.NET Core的日志模型借助TraceSourceLoggerProvider实现对TraceSource的整合,在正式介绍这个Logger之前,我们先来认识一下TraceSource跟踪日志系统中的三个核心对象阅读全文
posted @ 2016-09-13 09:33 Artech 阅读(3279) 评论(4) 编辑
摘要: 面向Windows的编程人员应该不会对Event Log感到陌生,以至于很多人提到日志,首先想到的就是EventLog。EventLog不仅仅记录了Windows系统自身针对各种事件的日志,我们的应用也可以利用提供的API将日志消息写到EventLog中。与EventLog相关的API都定义在System.Diagnostics.EventLog这个类型中,我们不仅仅可以利用它读取、写入和删除日志,还可以使用它来创建和删除Event Source。.NET Core的日志模型利用EventLogLogger实现了与EventLog的集成,不过EventLogLogger使用的是一个抽象化的EventLog。阅读全文
posted @ 2016-09-12 12:03 Artech 阅读(2579) 评论(5) 编辑
摘要: 定义在NuGet包“Microsoft.Extensions.Logging.Debug”中的DebugLogger会直接调用Debug的WriteLine方法来写入分发给它的日志消息。如果需要使用DebugLogger来写日志,我们需要将它的提供者DebugLoggerProvider注册到LoggerFactory上。由于定义在Debug类型中的所有方法都是针对Debug编译模式的,所以在只有针对Debug模式编译的应用中使用DebugLogger才有意义。这里将的“Debug编译模式”涉及到一个叫做“条件编译”的话题。阅读全文
posted @ 2016-08-25 08:26 Artech 阅读(2277) 评论(1) 编辑
摘要: 对于一个控制台应用,比如采用控制台应用作为宿主的ASP.NET Core应用,我们可以将记录的日志直接输出到控制台上。针对控制台的Logger是一个类型为ConsoleLogger的对象,ConsoleLogger对应的LoggerProvider类型为ConsoleLoggerProvider,这两个类型都定义在 NuGet包“Microsoft.Extensions.Logging.Console”之中。阅读全文
posted @ 2016-08-24 06:10 Artech 阅读(3582) 评论(2) 编辑
摘要: 配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。要了解配置同步机制的实现原理,先得从认识一个名为ConfigurationReloadToken的类型开始。阅读全文
posted @ 2016-08-18 06:56 Artech 阅读(1965) 评论(2) 编辑
摘要: 记录各种级别的日志是所有应用不可或缺的功能。关于日志记录的实现,我们有太多第三方框架可供选择,比如Log4Net、NLog、Loggr和Serilog 等,当然我们还可以选择微软原生的诊断框架(相关API定义在命名空间“System.Diagnostics”中)实现对日志的记录。.NET Core提供了独立的日志模型使我们可以采用统一的API来完成针对日志记录的编程,我们同时也可以利用其扩展点对这个模型进行定制,比如可以将上述这些成熟的日志框架整合到我们的应用中。阅读全文
posted @ 2016-08-17 08:33 Artech 阅读(6598) 评论(8) 编辑
摘要: 物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说,我们习以为常的XML反倒不是理想的配置源,至少和JSON比较起来,它具有一个先天不足的劣势,那就是针对集合数据结构的支持不如人意。[阅读全文
posted @ 2016-08-15 06:55 Artech 阅读(2340) 评论(9) 编辑
摘要: 配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。接下来我们利用一个简单的.NET Core控制台应用来演示针对文件的配置会涉及到数据同步的问题,我们希望应用能够对原始配置文件实施监控,并在文件内容发生改变的时候从新加载并应用新的配置。阅读全文
posted @ 2016-08-12 07:24 Artech 阅读(2341) 评论(10) 编辑
摘要: 如果预定义的ConfigurationSource依然不能满足项目中的配置需求,我们可以还可以通过自定义ConfigurationSource来支持我们希望的配置来源。就配置数据的持久化方式来说,将培植存储在数据库中应该是一种非常常见的方式,接下来我们就是创建一个针对数据库的ConfigurationSource,它采用最新的Entity Framework Core来完成数据库的存取操作。阅读全文
posted @ 2016-08-11 07:12 Artech 阅读(2979) 评论(1) 编辑
摘要: 物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。阅读全文
posted @ 2016-08-04 08:37 Artech 阅读(2998) 评论(2) 编辑
摘要: 较之传统通过App.config和Web.config这两个XML文件承载的配置系统,.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。阅读全文
posted @ 2016-08-03 07:21 Artech 阅读(3294) 评论(1) 编辑
摘要: 一个物理文件可以直接作为资源内嵌到编译生成的程序集中。借助于EmbeddedFileProvider,我们可以统一的编程方式来读取内嵌于某个程序集中的资源文件阅读全文
posted @ 2016-08-01 23:17 Artech 阅读(2518) 评论(4) 编辑
摘要: ASP.NET Core应用中使用得最多的还是具体的物理文件,比如配置文件、View文件以及网页上的静态文件,物理文件系统的抽象通过PhysicalFileProvider这个FileProvider来实现,该类型定义在NuGet包“Microsoft.Extensions.FileProviders.Physical”中。我们知道System.IO命名空间下定义了一整套针操作物理目录和文件的API,实际上PhysicalFileProvider最终也是通过调用这些API来完成相关的IO操作的。[阅读全文
posted @ 2016-07-31 23:17 Artech 阅读(2919) 评论(5) 编辑
摘要: 在《读取并监控文件的变化》中,我们通过三个简单的实例演示从编程的角度对文件系统做了初步的体验,接下来我们继续从设计的角度来继续认识它。这个抽象的文件系统以目录的形式来组织文件,我们可以利用它读取某个文件的内容,还可以对目标文件试试监控并捕捉它的变化。这些基本的功能均由相应的FileProvider来提供,从某种意义上讲FileProvider代表了整个文件系统。阅读全文
posted @ 2016-07-27 08:37 Artech 阅读(3640) 评论(5) 编辑
摘要: ASP.NET Core 具有很多针对文件读取的应用。比如我们倾向于采用JSON文件来定义配置,所以应用就会涉及针对配置文件读取。如果用户发送一个针对物理文件的HTTP请求,应用会根据指定的路径读取目标文件的内容并对请求予以响应。在一个ASP.NET Core MVC应用中,针对View的动态编译会涉及到根据预定义的路径映射关系来读取目标View。这些不同应用场景都会出现一个FileProvider对象的身影,以此对象为核心的文件系统提供了统一的API来读取文件的内容并监控内容的改变。阅读全文
posted @ 2016-07-25 09:15 Artech 阅读(8070) 评论(19) 编辑
摘要: 旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上。配置绑定的目标类型可以是一个简单的基元类型,也可以是一个自定义数据类型,还可以是一个数组、集合或者字典类型。通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典,那么针对这些完全不同的目标类型,原始的配置数据如何通过数据字典的形式来体现呢?阅读全文
posted @ 2016-07-21 23:19 Artech 阅读(2165) 评论(12) 编辑
摘要: 置的原子结构就是单纯的键值对,并且键和值都是字符串,但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置。值得推荐的做法就是将相关的配置定义成一个Options类型,并采用与类型定义想匹配的结构来定义原始的配置,这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象,我们将这种编程模式称为“Options模式”。阅读全文
posted @ 2016-07-20 23:15 Artech 阅读(3074) 评论(6) 编辑
摘要: 在《.NET Core采用的全新配置系统[1]: 读取配置数据》中,我们通过实例的方式演示了几种典型的配置读取方式,其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识,接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道,配置的编程模型涉及到三个核心对象,它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统,还缺少另一个名为ConfigurationProvider的核心对象,总得来说,.NET Core的这个配置模型由这四个核心对象组成。阅读全文
posted @ 2016-07-18 00:11 Artech 阅读(4088) 评论(9) 编辑
摘要: 提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。阅读全文
posted @ 2016-07-14 22:17 Artech 阅读(9054) 评论(37) 编辑
摘要: 之前写了一系列关于.NET Core/ASP.NET Core的文章,但是大都是针对RC版本。到了正式的RTM,很多地方都发生了改变,所以我会将之前发布的文章针对正式版本的.NET Core 1.0进行改写。除此之外,我还会撰写一系列与此相关的文章,这些文章以ASP.NET Core为核心,我个人将它们分成三个主要的部分,即编程基础、支撑框架和管道详解。其中编程基础主要涉及与ASP.NET Core独特的编程模型和相关编程技巧。支撑框架则介绍支撑ASP.NET Core的多个独立的框架,比如依赖注入、配置模型、配置管理等等。至于最后一部分管道详解,我们会介绍ASP.NET Core最为核心的部分,即用以处理请求的管道阅读全文
posted @ 2016-07-13 09:04 Artech 阅读(52141) 评论(75) 编辑
摘要: ASP.NET Core的核心是通过一个Server和若干注册的Middleware构成的管道,不论是管道自身的构建,还是Server和Middleware自身的实现,以及构建在这个管道的应用,都需要相应的服务提供支持,ASP.NET Core自身提供了一个DI容器来实现针对服务的注册和消费。换句话说,不只是ASP.NET Core底层框架使用的服务是由这个DI容器来注册和提供,应用级别的服务的注册和提供也需要以来这个DI容器,所以正如本文标题所说的——学习ASP.NET Core,你必须了解无处不在的“依赖注入”。阅读全文
posted @ 2016-07-04 08:31 Artech 阅读(32394) 评论(47) 编辑
共17页: 上一页 1 2 3 4 5 6 7 8 9 下一页 末页