配置验证在.NET

我执行一个系统监视项目稍微复杂的配置部分：配置验证在.NET

<monitoring> 
    <components> 
    <component name="Remote Server" 
       statusProviderType="ClientEndpoint" 
       statusProviderName="endpoint1" /> 
    </components> 
</montioring> 

<system.serviceModel> 
    <client> 
    <endpoint name="endpoint1"/> 
    <!-- Config removed for brevity --> 
    </client> 
</system.serviceModel>

如在上面的例子中，这些配置元素可以参考其他配置元素。在这种情况下，客户端端点必须实施作为监控项目一部分的预定合同。

内置配置处理处理任何明显的语法错误和值超出有效范围的简单错误。问题是配置是更复杂的错误的来源：

引用一个不存在的元素。
引用不符合某些条件的类型。

很明显，我希望捡起这些错误，但应该在应用程序中进行验证？

我目前考虑这些选项，但我不知道任何人是正确的：

配置元素验证本身和在读它抛出异常。将所有内容保持在配置级别，但在尝试“构建”配置节以将其写入配置文件时会引入问题。
使用配置的组件会在配置值传递给它时验证配置值，并根据收到的信息抛出异常。允许配置元素具有更大的灵活性，但更难确定问题的来源。
使用配置的组件验证其操作所需的配置，并在配置无效时抛出异常。这很好地将行为从配置中分离出来，但是当配置成为问题的根源时，它就不那么明显了。

此外，哪些异常适合抛出我可能处理的错误种类？奖金积分与你的答案有很好的推理。我很想知道所有可用的选项，但知道如何配置可以调试一些系统，我真的想要一个明智的解决方案。

来源

2009-11-19 Paul Turner

我就走了，问了一些同事，调查了.NET类如何处理这类问题，来到了一些澄清：

配置是一个简单的方法来配置对象实例，常作为很简单，就是为新实例指定默认值。配置文件中的可用值通常也可用于在代码中设置。
配置不当的实例抛出InvalidOperationException并派生类指示对象状态中的错误。它不表示，其中配置问题来自。
如果配置的有效性足以设置实例，即使实例无法正确运行，该错误也不再被专门分类为“配置文件”问题。

显然，这给了我一些规则，我可以坚持，值得高兴的事情我的配置系统：

如果错误可以在配置文件中的值内被检测（如串以不正确的格式，不实现接口的类型），错误是配置级错误并指示配置文件有问题。应该由配置部分执行验证，并在从配置文件中读取部分时引发异常。
如果在一个值内不能检测到错误，应该可以从这些值中初始化一个实例，而不会抛出任何异常。避免在这里抛出异常，并考虑重构类将现有异常移到别处。在这个阶段，与配置无关的异常很难调试，因为通常没有可用的状态来调试。如果在这里抛出异常必须，它们应该由与配置相关的异常包装，并应引用导致问题的元素。
如果在加载配置后发生任何错误，则该问题将由对象实例作为InvalidOperationException或类似问题处理，因为它不知道它的工作值来自哪里，因此只能指示其状态不正确。

其他人应该做复杂的配置，我希望这有助于。

来源

2009-11-23 11:00:43

使用DTD和XML验证工具。 Here is the description

来源

2009-11-19 17:26:14 Elalfer

验证XML已由.NET配置系统充分执行。我期望检测到的错误比这些更复杂。 – 2009-11-19 17:34:55

配置验证在.NET

回答

相关问题