C# Application Settings中User与Application作用域校验疑问

先提一句，你贴的这段示例代码有个低级笔误：存应用作用域检测结果的变量叫flag1，后面判断的时候写的是没定义的flag2，真要跑先把这个bug改了。

官方API会不会从根上拦住这两种非法配置？ #

不会全环节拦，得看你怎么创建设置项：

• 要是你老老实实用VS自带的设置设计器生成强类型Settings类，设计器本身就不让你给单个设置同时选用户/应用两个作用域，也不可能生成没打作用域标记的配置项，这种情况出来的配置天生是合法的，不会有问题。
• 但.NET底层的SettingsProperty相关API根本没在对象初始化的时候做校验，你完全可以手动new一个SettingsProperty，想往Attributes里加几个作用域特性就加几个，哪怕两个都加、两个都不加也没人管。官方自己的校验逻辑是等到设置提供器真要读/写这个配置项、必须确定作用域的时候才会跑，逻辑和你贴的这段几乎一模一样。

实际写业务要不要加这类校验？ #

看你怎么用配置：

• 要是你整个项目的设置全是用设计器生成的，既不写自定义设置提供器，也不在运行时动态拼配置项，完全没必要加。系统自己在读写配置的时候就会做校验，真出问题程序启动加载配置的时候就炸了，根本跑不到业务逻辑里。
• 要是你要做配置相关的通用工具、自定义配置存储逻辑，或者需要遍历所有配置项做批量操作（比如批量导出用户设置、批量清理配置），那加这个校验很值。毕竟你没法保证传到方法里的SettingsProperty都是系统生成的合法对象，在自己代码入口就把错抛了，比等错抛到底层存储组件里、翻半天堆栈找问题方便多了。

这段校验是不是过度设计？ #

改完笔误的话不算，但适用场景很窄。
这就是个很标准的防御性编程写法，把底层要做的校验提前到自己方法的入口，放在通用类库、基础组件里完全没问题。但如果就是个普通业务系统，所有配置都是设计器拖出来的，也不做啥配置扩展，硬塞这段逻辑就纯属多余，写了也永远触发不了，纯纯的无效代码。

多提一句：全用设计器生成强类型配置的场景下，你连判断作用域的方法都没必要写——每个配置项对应的属性在生成的时候作用域就定死了，根本不需要运行时靠反射特性去判断。

内容的提问来源于stack exchange，提问作者dannyhut