用于检查XML配置文件内部一致性的工具、规则或过程

我从事过一些具有非常复杂的XML配置的项目，面临的一个问题是维护XML的内部一致性

在本例中，我指的不是严格的XML模式一致性，而是所用节点之间的更高级别关系。大多数问题是由XML中编码的信息之间的隐式链接以及该信息与代码库的隐式关系引起的。例如：

• 在代码中隐式链接到枚举的XML节点数据
• 同一配置中相关的业务对象（因为它们共享需要一致的信息），而它们之间没有任何明确的关系
• 要在运行时编译和解析的XML代码

我突然想到，a）这可能会成为一种增加频率的做法，b）在某些情况下，我们会隐式地创建一种新的编码语言，这种语言没有编译时检查——事实上，在运行之前几乎没有检查

是否还有其他人面临类似的情况，是否有任何工具或方法使问题更容易处理？我想要一些与技术无关的通用示例——我自己的具体经验是使用C#和专有系统的配置

---

注意：虽然我在下面有一个答案，但我并不打算把我自己的答案作为最终答案。

这将在很大程度上取决于您在项目中使用的语言/框架/工具

使用XML进行配置确实会有问题，因为它无法在编译时进行检查

例如，当使用Java和时，存在一个名为的Eclipse插件，它可以在XML配置和实际代码之间执行同步检查

但这只是特定语言和特定框架的一个示例。你应该试着找出你的场景中是否存在类似的东西

顺便说一句，如果您让我们知道您正在使用什么技术，我们可能会为您提供更多帮助。

您尝试过Schematron吗？

它是一种更高级的语言，目标是在语义上验证XML，而不仅仅是在语法上

---

另请参见维基百科：

来自@David Peleg's is的一个很好的链接，它提供了检查XML的产品，包括“业务规则”检查。

我使用自动功能测试来确保工作中默认配置的数据完整性。我不知道您描述的问题必然依赖于XML的配置格式。尽管如此，我建议：

• 您不使用XML作为配置格式。（谷歌可以告诉你原因）
• 通过隐式使用枚举或任何其他构造值实现的紧密耦合在配置中与在代码中一样糟糕
• 从配置中提取并执行的代码让我畏缩。它是否在配置中以便可以重写？如果是这样的话，那将是bug、未定义行为和潜在安全问题的巨大载体
• 业务对象问题听起来也像是严重的紧耦合

您可能无法对XML进行任何处理，例如配置格式、错误耦合或从配置执行代码。您可以通过创建一套功能测试来降低风险，以确保：

• 枚举是有效的
• 代码是可编译的、可执行的，不包含evals、rpc调用、不调用函数或任何其他要添加的分析检查

---

有时，您还可以通过提供一个备选方案（配置或配置条目）来帮助进行更改

谢谢。实际上，我想保持这种语言和系统的不可知性，因为它实际上与业务规则有关。也就是说，我将添加一条关于我通常使用的语言的评论。我想保持这种语言/技术的不可知性——但我通常使用C#。感谢您的回复——我一直在想如何编写测试。例如，我想知道如何使用匹配的标记标记xml节点和代码，以便自动化测试能够匹配它们。你做了什么特别的事情来编写你的测试吗？顺便说一句：非常同意配置中的代码是各种不好的向量。与其标记xml节点和代码，不如考虑消除紧密耦合。我的测试通常是对特定代码段的功能测试、变体测试和单元测试的修复。是的，在大型生产系统中，在做看似正确的事情和看似可能的事情之间存在着一种真正的紧张关系。最让我担心的是，它让我们远离了棕地重构，而棕地重构实际上可能给我们留下一个更好的系统。