共17页: 上一页 1 2 3 4 5 6 7 8 9 下一页 末页 
摘要: ASP.NET Core管道由注册的服务器和一系列中间件构成。我们在上一篇中深入剖析了中间件,现在我们来了解一下服务器。服务器是ASP .NET Core管道的第一个节点,它负责完整请求的监听和接收,最终对请求的响应同样也由它完成。服务器是我们对所有实现了IServer接口的所有类型以及对应对象的统称。阅读全文
posted @ 2016-11-15 08:16 Artech 阅读(1983) 评论(6) 编辑
摘要: ASP.NET Core管道虽然在结构组成上显得非常简单,但是在具体实现上却涉及到太多的对象,所以我们在 “通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程”(上篇、中篇、下篇) 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在本系列 中,我们会还原构建模拟管道时可以舍弃和改写的部分,向读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个服务器与一组有序排列的中间件构成,前者仅仅完成请求监听、接收和响应这些与底层网络相关的工作,至于请求接收之后和响应之前的所有工作都交给中间件来完成。阅读全文
posted @ 2016-11-14 08:35 Artech 阅读(3770) 评论(12) 编辑
摘要: 论是JavaScript还是C#程序,我们已经习惯了采用“链式调用”的方式进行编程,这样确实会使我们的程序变得很精练。采用这种链式调用方式的很多方式都是扩展方法。我们在定义这种扩展方法的时候,有一个地方值得我们注意。阅读全文
posted @ 2016-10-26 14:48 Artech 阅读(2761) 评论(7) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-13 23:01 Artech 阅读(2317) 评论(5) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-12 22:53 Artech 阅读(2914) 评论(9) 编辑
摘要: ASP.NET Core请求处理管道由一个服务器和一组中间件构成。如果想非常深刻地认识ASP.NET Core的请求处理管道,我觉得可以分两个步骤来进行:首先,我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程;在对总体流程有了大致了解之后,我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程,我们根据真实管道的实现原理再造了一个“迷你版的管道”。阅读全文
posted @ 2016-10-11 22:52 Artech 阅读(3768) 评论(3) 编辑
摘要: FileProvider构建了一个抽象文件系统,作为它的两个具体实现,PhysicalFileProvider和EmbeddedFileProvider则分别为我们构建了一个物理文件系统和程序集内嵌文件系统。总的来说,它们针对的都是“本地”文件,接下来我们通过自定义FileProvider构建一个“远程”文件系统,我们可以将它视为一个只读的“云盘”。由于文件系统的目录结构和文件内容都是通过HTTP请求的方式读取的,所以我们将这个自定义的FileProvider命名为HttpFileProvider。阅读全文
posted @ 2016-09-29 08:38 Artech 阅读(3125) 评论(5) 编辑
摘要: 这是今天作项目支持的发现的一个关于WCF的问题,虽然最终我只是添加了一行代码就解决了这个问题,但是整个纠错过程是痛苦的,甚至最终发现这个问题都具有偶然性。具体来说,这是一个关于如何自动为服务接口(契约)的每个操作添加FaultContract与WCF服务元数据发布的问题。接下来通过一个简单的实例来说明这个因为少写了一行代码引发的血案。阅读全文
posted @ 2016-09-21 14:43 Artech 阅读(4503) 评论(13) 编辑
摘要: ETW是Event Tracing for Windows的简称,它是Windows提供的原生的事件跟踪日志系统。由于采用内核(Kernel)层面的缓冲和日志记录机制,所以ETW提供了一种非常高效的事件跟踪日志解决方案。阅读全文
posted @ 2016-09-14 08:23 Artech 阅读(3283) 评论(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 阅读(2808) 评论(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 阅读(2280) 评论(5) 编辑
摘要: 定义在NuGet包“Microsoft.Extensions.Logging.Debug”中的DebugLogger会直接调用Debug的WriteLine方法来写入分发给它的日志消息。如果需要使用DebugLogger来写日志,我们需要将它的提供者DebugLoggerProvider注册到LoggerFactory上。由于定义在Debug类型中的所有方法都是针对Debug编译模式的,所以在只有针对Debug模式编译的应用中使用DebugLogger才有意义。这里将的“Debug编译模式”涉及到一个叫做“条件编译”的话题。阅读全文
posted @ 2016-08-25 08:26 Artech 阅读(2082) 评论(1) 编辑
摘要: 对于一个控制台应用,比如采用控制台应用作为宿主的ASP.NET Core应用,我们可以将记录的日志直接输出到控制台上。针对控制台的Logger是一个类型为ConsoleLogger的对象,ConsoleLogger对应的LoggerProvider类型为ConsoleLoggerProvider,这两个类型都定义在 NuGet包“Microsoft.Extensions.Logging.Console”之中。阅读全文
posted @ 2016-08-24 06:10 Artech 阅读(2914) 评论(2) 编辑
摘要: 配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。要了解配置同步机制的实现原理,先得从认识一个名为ConfigurationReloadToken的类型开始。阅读全文
posted @ 2016-08-18 06:56 Artech 阅读(1835) 评论(2) 编辑
摘要: 记录各种级别的日志是所有应用不可或缺的功能。关于日志记录的实现,我们有太多第三方框架可供选择,比如Log4Net、NLog、Loggr和Serilog 等,当然我们还可以选择微软原生的诊断框架(相关API定义在命名空间“System.Diagnostics”中)实现对日志的记录。.NET Core提供了独立的日志模型使我们可以采用统一的API来完成针对日志记录的编程,我们同时也可以利用其扩展点对这个模型进行定制,比如可以将上述这些成熟的日志框架整合到我们的应用中。阅读全文
posted @ 2016-08-17 08:33 Artech 阅读(5347) 评论(8) 编辑
摘要: 物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说,我们习以为常的XML反倒不是理想的配置源,至少和JSON比较起来,它具有一个先天不足的劣势,那就是针对集合数据结构的支持不如人意。[阅读全文
posted @ 2016-08-15 06:55 Artech 阅读(2186) 评论(9) 编辑
摘要: 配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。接下来我们利用一个简单的.NET Core控制台应用来演示针对文件的配置会涉及到数据同步的问题,我们希望应用能够对原始配置文件实施监控,并在文件内容发生改变的时候从新加载并应用新的配置。阅读全文
posted @ 2016-08-12 07:24 Artech 阅读(2125) 评论(10) 编辑
摘要: 如果预定义的ConfigurationSource依然不能满足项目中的配置需求,我们可以还可以通过自定义ConfigurationSource来支持我们希望的配置来源。就配置数据的持久化方式来说,将培植存储在数据库中应该是一种非常常见的方式,接下来我们就是创建一个针对数据库的ConfigurationSource,它采用最新的Entity Framework Core来完成数据库的存取操作。阅读全文
posted @ 2016-08-11 07:12 Artech 阅读(2777) 评论(1) 编辑
摘要: 物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。阅读全文
posted @ 2016-08-04 08:37 Artech 阅读(2787) 评论(2) 编辑
摘要: 较之传统通过App.config和Web.config这两个XML文件承载的配置系统,.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。阅读全文
posted @ 2016-08-03 07:21 Artech 阅读(2897) 评论(1) 编辑
摘要: 一个物理文件可以直接作为资源内嵌到编译生成的程序集中。借助于EmbeddedFileProvider,我们可以统一的编程方式来读取内嵌于某个程序集中的资源文件阅读全文
posted @ 2016-08-01 23:17 Artech 阅读(2158) 评论(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 阅读(2448) 评论(4) 编辑
摘要: 在《读取并监控文件的变化》中,我们通过三个简单的实例演示从编程的角度对文件系统做了初步的体验,接下来我们继续从设计的角度来继续认识它。这个抽象的文件系统以目录的形式来组织文件,我们可以利用它读取某个文件的内容,还可以对目标文件试试监控并捕捉它的变化。这些基本的功能均由相应的FileProvider来提供,从某种意义上讲FileProvider代表了整个文件系统。阅读全文
posted @ 2016-07-27 08:37 Artech 阅读(3227) 评论(5) 编辑
摘要: ASP.NET Core 具有很多针对文件读取的应用。比如我们倾向于采用JSON文件来定义配置,所以应用就会涉及针对配置文件读取。如果用户发送一个针对物理文件的HTTP请求,应用会根据指定的路径读取目标文件的内容并对请求予以响应。在一个ASP.NET Core MVC应用中,针对View的动态编译会涉及到根据预定义的路径映射关系来读取目标View。这些不同应用场景都会出现一个FileProvider对象的身影,以此对象为核心的文件系统提供了统一的API来读取文件的内容并监控内容的改变。阅读全文
posted @ 2016-07-25 09:15 Artech 阅读(7250) 评论(19) 编辑
摘要: 旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上。配置绑定的目标类型可以是一个简单的基元类型,也可以是一个自定义数据类型,还可以是一个数组、集合或者字典类型。通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典,那么针对这些完全不同的目标类型,原始的配置数据如何通过数据字典的形式来体现呢?阅读全文
posted @ 2016-07-21 23:19 Artech 阅读(1890) 评论(10) 编辑
摘要: 置的原子结构就是单纯的键值对,并且键和值都是字符串,但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置。值得推荐的做法就是将相关的配置定义成一个Options类型,并采用与类型定义想匹配的结构来定义原始的配置,这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象,我们将这种编程模式称为“Options模式”。阅读全文
posted @ 2016-07-20 23:15 Artech 阅读(2711) 评论(6) 编辑
摘要: 在《.NET Core采用的全新配置系统[1]: 读取配置数据》中,我们通过实例的方式演示了几种典型的配置读取方式,其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识,接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道,配置的编程模型涉及到三个核心对象,它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统,还缺少另一个名为ConfigurationProvider的核心对象,总得来说,.NET Core的这个配置模型由这四个核心对象组成。阅读全文
posted @ 2016-07-18 00:11 Artech 阅读(3597) 评论(9) 编辑
摘要: 提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。阅读全文
posted @ 2016-07-14 22:17 Artech 阅读(8012) 评论(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 阅读(45047) 评论(68) 编辑
摘要: 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 阅读(28947) 评论(47) 编辑
摘要: 2016年6月27日,这是一个特殊的日子,微软全新的.NET开发平台.NET Core的RTM版本正式发布。我个人将.NET Core的核心特性归结为三点,它们的首字母组成一个非常好记的简称——COM,分别代表的含义Cross-Platform、Open-Source和Modularization。开发.NET Core应用的方式与之前具有非常大的变化,对于那些尚未体验过.NET Core的朋友,我希望通过本篇文章创建的这一个Hello World应用可以很容易地带你们入门。阅读全文
posted @ 2016-06-30 23:19 Artech 阅读(18155) 评论(80) 编辑
摘要: 对于.NET开发人员来说,我们已经习惯了VS这个世界上最强大的IDE,所以对他们来说,项目的创建直接利用安装到VS中相应的项目模板即可。当.NET Core跨出了Windows的围栏,正式拥抱其他平台,意味着VS已经不再是唯一的IDE。于此同时,.NET Core充分借鉴了目前非常流行的基于“脚手架(Scaffolding)”的源文件生成方式,在它的核心命令行“dotnet”也添加了脚手架的命令行开关。除此之外,.NET Core真正对社区敞开胸怀,我们可以直接利用现有的脚手架工具Yeoman来生成.NET Core项目。接下来我们就来介绍一下两种生成.NET Core项目的方式。阅读全文
posted @ 2016-06-29 22:38 Artech 阅读(15984) 评论(58) 编辑
摘要: 我们在上面对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了详细介绍(《聊聊ASP.NET Core默认提供的这个跨平台的服务器——KestrelServer》),为了让读者朋友们对管道中的Server具有更加深刻的认识,接下来我们采用实例演示的形式创建一个自定义的Server。这个自定义的Server直接利用HttpListener来完成针对请求的监听、接收和响应,我们将其命名为HttpListenerServer。在正式介绍HttpListenerServer的设计和实现之前,我们先来显示一下如何将它应用到 一个具体的Web应用中。阅读全文
posted @ 2016-06-21 07:30 Artech 阅读(2202) 评论(8) 编辑
摘要: 跨平台是ASP.NET Core一个显著的特性,而KestrelServer是目前微软推出了唯一一个能够真正跨平台的Server。KestrelServer利用一个名为KestrelEngine的网络引擎实现对请求的监听、接收和响应。KetrelServer之所以具有跨平台的特质,源于KestrelEngine是在一个名为libuv的跨平台网络库上开发的。阅读全文
posted @ 2016-06-20 09:10 Artech 阅读(12268) 评论(14) 编辑
摘要: Server是ASP .NET Core管道的第一个节点,负责完整请求的监听和接收,最终对请求的响应同样也由它完成。Server是我们对所有实现了IServer接口的所有类型以及对应对象的统称,这个接口具有一个只读属性Features返回描述自身特性集合的FeatureCollection对象,另一个Start方法用于启动服务器。阅读全文
posted @ 2016-06-16 23:16 Artech 阅读(2209) 评论(3) 编辑
摘要: ASP.NET Core管道虽然在结构组成上显得非常简单,但是在具体实现上却涉及到太多的对象,所以我们在 《ASP.NET Core管道深度剖析[共4篇]》 中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在这个系列 中,我们会还原构建模拟管道时可以舍弃和改写的部分,想读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个Server和一组有序排列的中间件构成,前者仅仅完成基本的请求监听、接收和响应的工作,请求接收之后和响应之前的所有工作都交给注册的中间件来完成。ASP.NET Core的中间件通过一个类型Func阅读全文
posted @ 2016-06-15 09:01 Artech 阅读(5545) 评论(6) 编辑
摘要: 当我们利用LoggerFactory创建一个Logger对象并利用它来实现日志记录,这个过程会产生一个日志消息,日志消息的流向取决于注册到LoggerFactory之上的LoggerProvider。说的更加具体一点,日志消息的归宿取决于注册到LoggerFactory的LoggerProvider究竟会提供怎样的Logger。微软提供了一系列原生的LoggerProvider,我们先来认识一下将控制台作为日志输出目的地的ConsoleLoggerProvider阅读全文
posted @ 2016-06-13 06:59 Artech 阅读(1473) 评论(0) 编辑
摘要: 除了在源代码层面实现共享(“前.NET Core时代”如何实现跨平台代码重用 ——源文件重用)之外,我们还可以跨平台共享同一个程序集,这种独立于具体平台的“中性”程序集通过创建一种名为“可移植类库(PCL: Portable Class Library)”项目来实现。为了让读者朋友们对PCL的实现机制具有充分的认识,我们先来讨论一个被我称为“程序集动态绑定”的话题。阅读全文
posted @ 2016-06-12 09:09 Artech 阅读(2563) 评论(2) 编辑
摘要: 对于包括Mono在内的各个.NET Framework平台的BCL(Basic Class Library)来说,虽然在API定义层面上存在一些共同之处,但是由于它们定义在不同的程序集之中,所以在PCL(Portal Class Library)推出之前,针对程序集的共享是不可能实现的,我们只能在源代码层面实现共享。源代码的共享通过在不同项目(针对不同.NET Framework平台)之间共享源文件的方式来实现,至于具体采用的方式,我们有三种不同的方案供你选择。阅读全文
posted @ 2016-06-09 00:17 Artech 阅读(1499) 评论(0) 编辑
摘要: NET Core的日志模型主要由三个核心对象构成,它们分别是Logger、LoggerProvider和LoggerFactory。总的来说,LoggerProvider提供一个具体的Logger对象将格式化的日志消息写入相应的目的地,但是我们在编程过程中使用的Logger对象则由LoggerFactory创建,这个Logger利用注册到LoggerFactory的LoggerProvider来提供真正具有日志写入功能的Logger,并委托后者来记录日志。阅读全文
posted @ 2016-06-07 23:00 Artech 阅读(3837) 评论(6) 编辑
共17页: 上一页 1 2 3 4 5 6 7 8 9 下一页 末页