Question

我正在为系统监控项目实现一个有点复杂的配置部分：

<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>

如上例所示，这些配置元素可以引用其他配置元素。在这种情况下，客户端端点必须实现预定合同，该合同是监控项目的一部分。

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

引用不存在的元素。
引用不符合特定条件的类型。

显然，我希望了解这些错误，但应该在应用程序中进行验证的位置？

到目前为止，我已经考虑了这些选项，但我不确定它们是否正确：

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

此外，哪些异常适合抛出我可能处理的错误？奖励积分与你的答案有充分的理由。

我对所有可用的选项感到相当无能为力，但是知道使用某些系统调试配置有多困难，我真的想要一个合理的解决方案。

Answer 1

我离开了，问了一些同事，研究了.NET类如何处理这类问题并得出了一些澄清：

配置只是配置对象实例的一种方法，通常与为新实例指定默认值一样简单。配置文件中可用的值通常也可以在代码中设置。
未正确配置的实例抛出InvalidOperationException并派生类以指示对象状态中的错误。它并不表示配置问题来自哪里。
如果配置足以有效设置实例，即使实例无法正确运行，错误也不会特别归类为“配置文件”问题。

显然，这给了我一些我可以坚持的规则，对我的配置系统感到高兴：

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

如果其他人正在进行复杂的配置，我希望这会有所帮助。

Answer 2

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

.NET中的配置验证

2 个答案: