[01] 技术剖析 - 随笔分类(第5页) - Artech

摘要：

ETW是Event Tracing for Windows的简称，它是Windows提供的原生的事件跟踪日志系统。由于采用内核（Kernel）层面的缓冲和日志记录机制，所以ETW提供了一种非常高效的事件跟踪日志解决方案。阅读全文

posted @ 2016-09-14 08:23 Artech 阅读(23382) 评论(1) 推荐(10) 编辑

摘要：

从微软推出第一个版本的.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 阅读(6604) 评论(6) 推荐(10) 编辑

.NET Core的日志[3]:将日志写入Debug窗口

摘要：

定义在NuGet包“Microsoft.Extensions.Logging.Debug”中的DebugLogger会直接调用Debug的WriteLine方法来写入分发给它的日志消息。如果需要使用DebugLogger来写日志，我们需要将它的提供者DebugLoggerProvider注册到LoggerFactory上。由于定义在Debug类型中的所有方法都是针对Debug编译模式的，所以在只有针对Debug模式编译的应用中使用DebugLogger才有意义。这里将的“Debug编译模式”涉及到一个叫做“条件编译”的话题。阅读全文

posted @ 2016-08-25 08:26 Artech 阅读(5530) 评论(1) 推荐(8) 编辑

.NET Core的日志[2]:将日志输出到控制台

摘要：

对于一个控制台应用，比如采用控制台应用作为宿主的ASP.NET Core应用，我们可以将记录的日志直接输出到控制台上。针对控制台的Logger是一个类型为ConsoleLogger的对象，ConsoleLogger对应的LoggerProvider类型为ConsoleLoggerProvider，这两个类型都定义在 NuGet包“Microsoft.Extensions.Logging.Console”之中。阅读全文

posted @ 2016-08-24 06:10 Artech 阅读(14970) 评论(2) 推荐(11) 编辑

.NET Core采用的全新配置系统[10]: 配置的同步机制是如何实现的？

摘要：

配置的同步涉及到两个方面：第一，对原始的配置文件实施监控并在其发生变化之后从新加载配置；第二，配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。要了解配置同步机制的实现原理，先得从认识一个名为ConfigurationReloadToken的类型开始。阅读全文

posted @ 2016-08-18 06:56 Artech 阅读(3118) 评论(3) 推荐(5) 编辑

.NET Core的日志[1]:采用统一的模式记录日志

摘要：

记录各种级别的日志是所有应用不可或缺的功能。关于日志记录的实现，我们有太多第三方框架可供选择，比如Log4Net、NLog、Loggr和Serilog 等，当然我们还可以选择微软原生的诊断框架（相关API定义在命名空间“System.Diagnostics”中）实现对日志的记录。.NET Core提供了独立的日志模型使我们可以采用统一的API来完成针对日志记录的编程，我们同时也可以利用其扩展点对这个模型进行定制，比如可以将上述这些成熟的日志框架整合到我们的应用中。阅读全文

posted @ 2016-08-17 08:33 Artech 阅读(13248) 评论(10) 推荐(18) 编辑

.NET Core采用的全新配置系统[9]: 为什么针对XML的支持不够好？如何改进？

摘要：

物理文件是我们最常用到的原始配置的载体，最佳的配置文件格式主要由三种，它们分别是JSON、XML和INI，对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说，我们习以为常的XML反倒不是理想的配置源，至少和JSON比较起来，它具有一个先天不足的劣势，那就是针对集合数据结构的支持不如人意。[ 阅读全文

posted @ 2016-08-15 06:55 Artech 阅读(4072) 评论(11) 推荐(9) 编辑

.NET Core采用的全新配置系统[8]: 如何实现配置与源文件的同步

摘要：

配置的同步涉及到两个方面：第一，对原始的配置文件实施监控并在其发生变化之后从新加载配置；第二，配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。接下来我们利用一个简单的.NET Core控制台应用来演示针对文件的配置会涉及到数据同步的问题，我们希望应用能够对原始配置文件实施监控，并在文件内容发生改变的时候从新加载并应用新的配置。阅读全文

posted @ 2016-08-12 07:24 Artech 阅读(4135) 评论(11) 推荐(13) 编辑

.NET Core采用的全新配置系统[7]: 将配置保存在数据库中

摘要：

如果预定义的ConfigurationSource依然不能满足项目中的配置需求，我们可以还可以通过自定义ConfigurationSource来支持我们希望的配置来源。就配置数据的持久化方式来说，将培植存储在数据库中应该是一种非常常见的方式，接下来我们就是创建一个针对数据库的ConfigurationSource，它采用最新的Entity Framework Core来完成数据库的存取操作。阅读全文

posted @ 2016-08-11 07:12 Artech 阅读(4833) 评论(1) 推荐(14) 编辑

.NET Core采用的全新配置系统[6]: 深入了解三种针对文件（JSON、XML与INI）的配置源

摘要：

物理文件是我们最常用到的原始配置的载体，最佳的配置文件格式主要由三种，它们分别是JSON、XML和INI，对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。阅读全文

posted @ 2016-08-04 08:37 Artech 阅读(5135) 评论(2) 推荐(10) 编辑

.NET Core采用的全新配置系统[5]: 聊聊默认支持的各种配置源[内存变量,环境变量和命令行参数]

摘要：

较之传统通过App.config和Web.config这两个XML文件承载的配置系统，.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源，如果采用物理文件作为配置源，我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求，我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。阅读全文

posted @ 2016-08-03 07:21 Artech 阅读(6522) 评论(1) 推荐(16) 编辑

.NET Core的文件系统[4]：由EmbeddedFileProvider构建的内嵌（资源）文件系统

摘要：

一个物理文件可以直接作为资源内嵌到编译生成的程序集中。借助于EmbeddedFileProvider，我们可以统一的编程方式来读取内嵌于某个程序集中的资源文件阅读全文

posted @ 2016-08-01 23:17 Artech 阅读(5729) 评论(4) 推荐(13) 编辑

.NET Core的文件系统[2]：FileProvider是个什么东西？

摘要：

在《读取并监控文件的变化》中，我们通过三个简单的实例演示从编程的角度对文件系统做了初步的体验，接下来我们继续从设计的角度来继续认识它。这个抽象的文件系统以目录的形式来组织文件，我们可以利用它读取某个文件的内容，还可以对目标文件试试监控并捕捉它的变化。这些基本的功能均由相应的FileProvider来提供，从某种意义上讲FileProvider代表了整个文件系统。阅读全文

posted @ 2016-07-27 08:37 Artech 阅读(8829) 评论(5) 推荐(18) 编辑

.NET Core的文件系统[1]：读取并监控文件的变化

摘要：

ASP.NET Core 具有很多针对文件读取的应用。比如我们倾向于采用JSON文件来定义配置，所以应用就会涉及针对配置文件读取。如果用户发送一个针对物理文件的HTTP请求，应用会根据指定的路径读取目标文件的内容并对请求予以响应。在一个ASP.NET Core MVC应用中，针对View的动态编译会涉及到根据预定义的路径映射关系来读取目标View。这些不同应用场景都会出现一个FileProvider对象的身影，以此对象为核心的文件系统提供了统一的API来读取文件的内容并监控内容的改变。阅读全文

posted @ 2016-07-25 09:15 Artech 阅读(15860) 评论(19) 推荐(35) 编辑

.NET Core采用的全新配置系统[4]: “Options模式”下各种类型的Options对象是如何绑定的？

摘要：

旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上。配置绑定的目标类型可以是一个简单的基元类型，也可以是一个自定义数据类型，还可以是一个数组、集合或者字典类型。通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典，那么针对这些完全不同的目标类型，原始的配置数据如何通过数据字典的形式来体现呢？阅读全文

posted @ 2016-07-21 23:19 Artech 阅读(4224) 评论(16) 推荐(15) 编辑

.NET Core采用的全新配置系统[3]: “Options模式”下的配置是如何绑定为Options对象

摘要：

置的原子结构就是单纯的键值对，并且键和值都是字符串，但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置。值得推荐的做法就是将相关的配置定义成一个Options类型，并采用与类型定义想匹配的结构来定义原始的配置，这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象，我们将这种编程模式称为“Options模式”。阅读全文

posted @ 2016-07-20 23:15 Artech 阅读(6568) 评论(6) 推荐(12) 编辑

.NET Core采用的全新配置系统[2]: 配置模型设计详解

摘要：

在《.NET Core采用的全新配置系统[1]: 读取配置数据》中，我们通过实例的方式演示了几种典型的配置读取方式，其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识，接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道，配置的编程模型涉及到三个核心对象，它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统，还缺少另一个名为ConfigurationProvider的核心对象，总得来说，.NET Core的这个配置模型由这四个核心对象组成。阅读全文

posted @ 2016-07-18 00:11 Artech 阅读(7324) 评论(11) 推荐(25) 编辑

.NET Core采用的全新配置系统[1]: 读取配置数据

摘要：

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

posted @ 2016-07-14 22:17 Artech 阅读(16125) 评论(37) 推荐(66) 编辑

ASP.NET Core框架揭秘（持续更新中…）

摘要：

之前写了一系列关于.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 阅读(93318) 评论(79) 推荐(169) 编辑

学习ASP.NET Core，你必须了解无处不在的“依赖注入”

摘要：

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 阅读(58566) 评论(54) 推荐(94) 编辑

随笔分类 - [01] 技术剖析

公告