使用 ConfigSource 特性 拆分 Web.config 文件
一个大项目里可能会有非常多个配置参数,有.Net自己支持的配置(比如WCF,AppSettings),还有一部分是自定义的配置(比如继承自ConfigurationSection和ConfigurationElement的配置类),当然还有一部分是第三方类库的配置(其实也是自定义的配置,比如AOP框架Unity),当这些配置变得越来越多的时候,维护起来变得相当困难,特别是config文件内容相当的长和文件的容量过大,过大的文件在Config初始化读取文件时会带来性能影响,这个时候使用configSouce指定外部的文件,拆分成多个不同的文件存储配置,增强可读性和可维护性,降低出错的风险。
MSDN里提到了3点好处:
-
Using include files can result in a more logical and modular structure for configuration files. (模块化管理文件)
-
File-access security and permissions can be used to restrict access to sections of configuration settings. (可控制不同配置文件的访问权限)
-
Settings in an include file that are not used during application initialization can be modified and reloaded without requiring an application restart. (修改不在应用程序初始化时候使用的参数,不需要重启应用)
很多文章里都也已经说了关于ConfigSouce的用法,根据MSDN说明,ConfigSouce只能用于ConfigurationSection对应的节点,比如
<appSettings configSource="Config\\AppSettings\\appSettings.config"> </appSettings>
在appSettings.config里
<appSettings> <add key="IOS" value=""/> <add key="Android" value=""/> </appSettings>
这里appSettings是定义在machine.config里configSection,这样.Net会自动找到对应文件。
对于appSettings,在Web.config里IDE会给你智能提示,告诉你它支持configSouce属性,但是有些不会,比如配置WCF服务的system.serviceModel/services节点,这种节点也是支持的,因为从machine.config里会看到,services也是一个ConfigurationSection
所以如下配置是正确的:
<services configSource="Config\\ServiceModel\\Services.config"> </services>
对于自定义的配置,或者第三方类库配置,因为都是继承了ConfigurationSection
所以如下配置也是正确的:
自定义的邮件相关配置
<VRentEmail configSource="Config\\VRentEmail\\VRentEmail.config"> </VRentEmail>
Unity的配置
<unity configSource="Config\\Unity\\Unity.config"> </unity>
使用了configSource后有一个明显的缺点就是,智能感知没有了