音乐自助建站,营销网站试用,网站注册了域名然后怎么做,wordpress首页编辑1. 欢呼 .NET Standard 时代我现在已不大提 .Net Core#xff0c;对于我来说#xff0c;未来的开发将是基于 .NET Standard#xff0c;不仅仅是 面向未来 #xff0c;也是 面向过去#xff1b;不只是 .Net Core 可以享受便利#xff0c; .NET Framework 不升级一样能享受… 1. 欢呼 .NET Standard 时代我现在已不大提 .Net Core对于我来说未来的开发将是基于 .NET Standard不仅仅是 面向未来 也是 面向过去不只是 .Net Core 可以享受便利 .NET Framework 不升级一样能享受 .NET Standard 带来的好处。(目前 .NET Standard 支持 .NET Framework 4.6.1)2. 传统配置的不足在我刚步足 .Net 的世界时曾经有过一个 困惑是不是所有的配置都必须写在 Web.Config 中而直到开始学习 .Net Core 的配置模式才意识到传统配置的不足除了 XML 我们可能还需要更多的配置来源支持比如 Json配置是否可以直接序列化成对象或者多种类型直接取出来就是 int而不只是 string修改配置后IIS 就重启了是否有办法不重启就能修改配置微服务或者说分布式应用下管理配置带来的困难很显然微软也意识到这些问题并且设计出了一个强大并且客制化的配置方式但是这也意味着从 AppSettings 中取出配置的时代也一去不复返。3. 初识 IConfiguration在开始探讨现代化配置设计之前我们先快速上手 .Net Core 中自带的 Microsoft.Extensions.Configuration。如前面提到的这不是 .Net Core 的专属。我们首先创建一个基于 .NET Framework 4.6.1 的控制台应用 ( 代码地址)然后安装我们所需要的依赖。Nuget Install Microsoft.Extensions.Configuration.JsonNuget Install Microsoft.Extensions.Configuration.Binder然后引入我们的配置文件 my.conf:最后输入如下的代码并启动微软 支持 的来源除了有内存来源、还有系统变量、Json 文件、XML 文件等多种配置来源同时社区的开源带来了更多可能性还支持诸如 consul、etcd 和 apollo 等 分布式配置中心。除了支持更多的配置来源外我们还观察到来源是否可以 缺省 、是否可以 重载 都是可以配置的。特别是自动重载这在 .NETFramework 时代是无法想象的每当我们修改 Web.config的配置文件时热心的 IIS 就会自动帮我们重启应用而用户在看到 500 的提示或者一片空白时不禁会发出这网站真烂的赞美。同时需要注意配置 iis 的安全避免可以直接访问配置的 json 文件最好的方法是把json后缀改为诸如 conf 等4. 配置防腐层虽然微软自带的 IConfiguration 已经足够用了但是让我们畅享下未来或者回到我让我困惑的问题。是不是所有的配置都将基于 IConfiguration 答案自然是否定的编程技术不停地在发展即使老而弥坚的 AppSetting 也难逃被淘汰的一天。所以为了让我们的架构更长远一些我们需要进行 防腐层的设计。而且如果你还在维护以前的老项目时你更是需要借助防腐层的魔法去抵消同事或者上司的顾虑。让我们重新审视配置的用法无非就是从某个 key 获取对应的值可能是字符串、也可能是个对象所以我们可以在最底层的类库或全局类库中定义一个 IConfigurationGeter 来满足我们的要求。而关于 IConfigurationGeter的实现,我们姑且叫它 ConfigurationGetter 基于防腐层的设计我们不能在底层的类库安装任何依赖。所以我们需要新建一个基础设施层或者在应用入口层实现。代码示例中可以看到是在不同的项目中以后我们所有的配置都是通过 IConfigurationGeter 获取这样就避免了在你的应用层(或者三层架构中的 BAL 层) 中引入 Microsoft.Extensions.Configuration 的依赖。当然可能有些人会觉得大材小用但实际上等你到了真正的开发你就会觉得其中的好处。不止是我.Net Core 的设计者早就意识到防腐层的重要性所以才会有 Microsoft.Extensions.Configuration.Abstractions 等一系列的只有接口的抽象基库。5. 静态获取配置虽然我们已经有了防腐层但显然我们还没考虑到实际的用法特别是如果你的应用还没有引入依赖注入的支持我们前面实现的防腐层对于你来说就是摸不着头脑。同时我还是很喜欢以前那种直接从 AppSetting 中取出配置的便捷。所以这里我们需要引入 服务定位器模式 来满足 静态获取配置 的便捷操作。做完这些基础工作我们还需要在应用入口函数念一句咒语让他生效。config.AddConfigurationGeterLocator();var myString ConfigurationGeterLocator.Current[myString];// myString现在我们就能像以前一样直接调用 ConfigurationGeterLocator.Current 来获取我们想要的配置了。6. 依赖注入的曙光现在假设我们摆脱了蛮荒时代有了依赖注入的武器使用配置最方便的用法莫不过直接注入一个配置对象在 .Net Core 中做法大致如下看到这里你可能会困惑怎么和官方推荐的 IOptions 用法不一样? 尽管它在官方文档备受到推崇然而在实际开发中我是几乎不会使用到的在我看来:不使用 IOptions 就已经得到了对应的效果使用 IOptionsSnapshot 才能约束配置是否需要热重载但实际这个并不好控制所以鸡肋我们已经有防腐层了再引入就是破坏了设计7. 约定优于配置的福音在微服务应用流行的今天我们需要的配置类会越来越多。我们不停地注入最终累死编辑器是否有自动化注入的方法来解放我们的键盘?答案自然是有的然而在动手实现之前我们需要立下 约定优于配置 的海誓山盟。首先对于所有的配置类他们都可以看作是一类或者某个接口的实现。联想我们刚刚注入 TestConfig 的时候是不是指定了配置节点 TestConfig 那么如果我们要自动注入的话是不是可以考虑直接使用类的唯一标志比如类的全名那么注入的方法就可以修改为如下:仅仅用了类的全名还不够体现 约定优于配置 的威力联系现实是不是配置的某些选项是有默认值的比如 TestConfig 的 DefauleVaule 。在没有配置 DefauleVaule 的情况下DefauleVaule 的值将为 默认值 即我们代码中的 Hello World 反之设置了 DefauleVaule 则会覆盖掉原来的默认值。8. 分布式配置中心在微服务流行的今天如果还是像以前一样人工改动配置文件那是十分麻烦而且容易出错的一件事情这就需要引入配置中心同时配置中心也必须是分布式的才能避免单点故障。8.1 ConsulConsul 目前是我的首选方案首先它足够简单部署方便同时已经够用了。如果你还使用过 Consul可以使用 Docker 一键部署:docker run -d -p 8500:8500 --name consul consul然后在应用入口项目中引入 Winton.Extensions.Configuration.Consul的依赖。因为是个人开源所以难免会有一些问题比如我装的版本就是 2.1.0-master0003它解决了 2.0.1 中的一些问题但还没有发布正式版。8.1.1 .Net Core 使用 Consul 配置中心如果你是 .Net Core 应用你需要在 Program.cs 配置 ConfigureAppConfiguration:同时由于 .Net 客户端与 Consul 之间交互会使用长轮询所以我们需要在关闭应用的同时也要记得把连接回收这就需要在 Startup.cs 的 Configure 中处理:8.1.2 .NET Framework 使用 Consul 配置中心同理对于 .NET Framework 应用来说也是需要做对应的处理在 Global.asax 中:8.1.3 配置 Consul我们所说的配置对于 Consul 来说就是 Key/Value 。我们有两种配置一种是把以前的json配置文件都写到一个key 中。另一种就是创建一个 key 的目录然后每个 Section 分开配置。9. 结语写这篇文章很大的动力是看到不少 .Net Core 初学者抱怨使用配置中的各种坑抱怨微软文档不够清晰同时也算是我两年来的一些开发经验总结。最后需要谈一下感想。感受最多的莫过于 .Net Core 开源带来的冲击有很多开发者兴致勃勃地想要把传统的项目重构成 .Net Core 项目然而思想却没有升级上去反而越觉得 .Net Core 各种不适。但是只要思想升级了即使开发 .NET Framework 应用 一样也是能享受 .NET Standard 带来的便利。原文地址:https://www.cnblogs.com/chenug/p/9610172.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
