随笔分类 - [02] 编程技巧
摘要:
物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说,我们习以为常的XML反倒不是理想的配置源,至少和JSON比较起来,它具有一个先天不足的劣势,那就是针对集合数据结构的支持不如人意。[
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。接下来我们利用一个简单的.NET Core控制台应用来演示针对文件的配置会涉及到数据同步的问题,我们希望应用能够对原始配置文件实施监控,并在文件内容发生改变的时候从新加载并应用新的配置。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
如果预定义的ConfigurationSource依然不能满足项目中的配置需求,我们可以还可以通过自定义ConfigurationSource来支持我们希望的配置来源。就配置数据的持久化方式来说,将培植存储在数据库中应该是一种非常常见的方式,接下来我们就是创建一个针对数据库的ConfigurationSource,它采用最新的Entity Framework Core来完成数据库的存取操作。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
较之传统通过App.config和Web.config这两个XML文件承载的配置系统,.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
ASP.NET Core应用中使用得最多的还是具体的物理文件,比如配置文件、View文件以及网页上的静态文件,物理文件系统的抽象通过PhysicalFileProvider这个FileProvider来实现,该类型定义在NuGet包“Microsoft.Extensions.FileProviders.Physical”中。我们知道System.IO命名空间下定义了一整套针操作物理目录和文件的API,实际上PhysicalFileProvider最终也是通过调用这些API来完成相关的IO操作的。[
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
ASP.NET Core 具有很多针对文件读取的应用。比如我们倾向于采用JSON文件来定义配置,所以应用就会涉及针对配置文件读取。如果用户发送一个针对物理文件的HTTP请求,应用会根据指定的路径读取目标文件的内容并对请求予以响应。在一个ASP.NET Core MVC应用中,针对View的动态编译会涉及到根据预定义的路径映射关系来读取目标View。这些不同应用场景都会出现一个FileProvider对象的身影,以此对象为核心的文件系统提供了统一的API来读取文件的内容并监控内容的改变。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上。配置绑定的目标类型可以是一个简单的基元类型,也可以是一个自定义数据类型,还可以是一个数组、集合或者字典类型。通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典,那么针对这些完全不同的目标类型,原始的配置数据如何通过数据字典的形式来体现呢?
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
置的原子结构就是单纯的键值对,并且键和值都是字符串,但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置。值得推荐的做法就是将相关的配置定义成一个Options类型,并采用与类型定义想匹配的结构来定义原始的配置,这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象,我们将这种编程模式称为“Options模式”。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
在《.NET Core采用的全新配置系统[1]: 读取配置数据》中,我们通过实例的方式演示了几种典型的配置读取方式,其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识,接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道,配置的编程模型涉及到三个核心对象,它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统,还缺少另一个名为ConfigurationProvider的核心对象,总得来说,.NET Core的这个配置模型由这四个核心对象组成。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
之前写了一系列关于.NET Core/ASP.NET Core的文章,但是大都是针对RC版本。到了正式的RTM,很多地方都发生了改变,所以我会将之前发布的文章针对正式版本的.NET Core 1.0进行改写。除此之外,我还会撰写一系列与此相关的文章,这些文章以ASP.NET Core为核心,我个人将它们分成三个主要的部分,即编程基础、支撑框架和管道详解。其中编程基础主要涉及与ASP.NET Core独特的编程模型和相关编程技巧。支撑框架则介绍支撑ASP.NET Core的多个独立的框架,比如依赖注入、配置模型、配置管理等等。至于最后一部分管道详解,我们会介绍ASP.NET Core最为核心的部分,即用以处理请求的管道
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
ASP.NET Core的核心是通过一个Server和若干注册的Middleware构成的管道,不论是管道自身的构建,还是Server和Middleware自身的实现,以及构建在这个管道的应用,都需要相应的服务提供支持,ASP.NET Core自身提供了一个DI容器来实现针对服务的注册和消费。换句话说,不只是ASP.NET Core底层框架使用的服务是由这个DI容器来注册和提供,应用级别的服务的注册和提供也需要以来这个DI容器,所以正如本文标题所说的——学习ASP.NET Core,你必须了解无处不在的“依赖注入”。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
2016年6月27日,这是一个特殊的日子,微软全新的.NET开发平台.NET Core的RTM版本正式发布。我个人将.NET Core的核心特性归结为三点,它们的首字母组成一个非常好记的简称——COM,分别代表的含义Cross-Platform、Open-Source和Modularization。开发.NET Core应用的方式与之前具有非常大的变化,对于那些尚未体验过.NET Core的朋友,我希望通过本篇文章创建的这一个Hello World应用可以很容易地带你们入门。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
对于.NET开发人员来说,我们已经习惯了VS这个世界上最强大的IDE,所以对他们来说,项目的创建直接利用安装到VS中相应的项目模板即可。当.NET Core跨出了Windows的围栏,正式拥抱其他平台,意味着VS已经不再是唯一的IDE。于此同时,.NET Core充分借鉴了目前非常流行的基于“脚手架(Scaffolding)”的源文件生成方式,在它的核心命令行“dotnet”也添加了脚手架的命令行开关。除此之外,.NET Core真正对社区敞开胸怀,我们可以直接利用现有的脚手架工具Yeoman来生成.NET Core项目。接下来我们就来介绍一下两种生成.NET Core项目的方式。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/o_.netcore.png)
摘要:
对于包括Mono在内的各个.NET Framework平台的BCL(Basic Class Library)来说,虽然在API定义层面上存在一些共同之处,但是由于它们定义在不同的程序集之中,所以在PCL(Portal Class Library)推出之前,针对程序集的共享是不可能实现的,我们只能在源代码层面实现共享。源代码的共享通过在不同项目(针对不同.NET Framework平台)之间共享源文件的方式来实现,至于具体采用的方式,我们有三种不同的方案供你选择。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Dotnet.png)
摘要:
今天写了一个简单的.NET Core RC2控制台程序,发现中文显示一直是乱码。查看操作系统设置,没有问题;查看源文件编码,也没有问题;甚至查看了Console字符编码相关的注册表,依然没有发现问题。难道NET Core到了RC2,莫非连一些常用的编码都不支持吗?
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Dotnet.png)
摘要:
在.NET Core 1.0.0 RC2即将正式发布之际,我也应应景,针对RC2 Preview版本编写一个史上最简单的MVC应用。由于VS 2015目前尚不支持,VS Code的智能感知尚欠火候,所以我们直接采用最原始的记事本来编写这个MVC应用。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Aspnet.png)
摘要:
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Aspnet.png)
摘要:
ConfigurationBuilder在生成以Configuration对象的时候会利用注册其中的ConfigurationProvider加载原始的配置数据,那么一旦配置源中的数据发生变化,应用程序中的使用的配置信息如何与之同步呢?如果需要在应用程序中实现对配置信息的实施同步,就需要对原始配置数据的进行监控,并在数据改变的时候重新加载配置数据。除此之外,重新加载的配置需要应用到程序中,我们必然需要一种通知机制。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Aspnet.png)
摘要:
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。
阅读全文
![](http://images.cnblogs.com/cnblogs_com/artech/158198/r_Aspnet.png)