在我正在处理的系统的特定部分，我们使用XSLT生成PDF和HTML文件（用于电子邮件，打印和显示）。正在打印的业务模型是代码 （c#）。
在设计架构时，我对打印文档的要求进行了特殊考虑，因为XSLT比C#更难使用（可能只是对我而言？）。例如，我从业务模型生成聚合值和表，以便在文档上显示。这些决策不能很好地转换为可能使用类似 Xml 的其他区域。
我现在面临着其他人也使用 Xml 的问题，因此破坏了 SoC。
我倾向于拍摄他们最初锁定的 Xml 的快照，并为他们提供一种新方法。我个人认为这没有问题（面对 DRY），但其他人可能很难理解这种权衡。我的推理有缺陷吗？有没有更好的方法？
我知道
这是个人的事情，但我的选择始终是将尽可能多的逻辑放在 XSLT 代码而不是 C# 代码中 - 与您正在做的事情相反。这意味着您正在使用更高级别的声明性语言，并且是专门为操作 XML 而设计的语言。当然，有一个学习曲线，但在学习曲线的顶部，你会发现阳光普照的高地。不要让自己被 XSLT 1.0 的限制所推迟：2.0 抛弃了所有这些问题，你只需要准备好放弃Microsoft并使用第三方技术（Microsoft大约十年前停止在 XML 领域做任何新的事情，但这并不意味着你必须停留在过去）。