Camel xml-to-xml转换是xslt仍然是要走的路？

Question

对于我的上一个camel项目，我使用xslt将传入的xml转换为适合发送到第三方Web服务的xml格式。这很好用。这仍然被认为是xml-to-xml映射的最佳方法，还是你们推荐的更好，性能更好的工具？

就我个人而言，我不介意xslt，但是我组织中其他开发人员的反馈是他们发现很难阅读和维护，特别是当转换相当复杂时。他们有一点意见。

我正在考虑的一个替代方法是在解组之前将java对象编组并转换回xml。这具有通过转换器对象更容易设置和维护的益处。然而，我担心对性能的影响，实现这一目标所需的操作数量会有所不同。

对你的想法感兴趣。

非常感谢

Answer 1

虽然我同意开发人员认为XSLT有点痛苦，但这并不是一件坏事。我怀疑从XML转换为POJO进行转换，然后转换回XML将成为性能杀手。有很多操作要做，这种方法的O符号将成为杀手锏。

免责声明：我不为Altova / Liquid Technologies工作。

不久前，我在一家大型银行工作，我们使用Altovas XML套件。他们有一个名为MapForce的产品，它可以在短短几年内简化XSLT的开发和维护。我能够教一个没有开发经验的人如何创建有效的XSLT。这是一个非常好的产品，但有点贵。下载eval副本并给它一个旋转。

Liquid XML还有一些工具可以帮助您平滑XSLT创建的粗糙边缘。

我强烈建议您将这些工具视为一种选择，因为它们可能会让您痛苦不堪。

Answer 2

XSLT的主要问题是学习曲线。你已经掌握了这门语言，这对你来说不是问题，但是对于那些仍然觉得这种方法很奇怪而且不熟悉的同事来说，这是一个问题。所以有一个两难的境地。为了减少组织中每个人必须学习的技术总数，使用次优技术来完成工作是完全可敬的。尽管如此，XSLT 2.0肯定是这项工作的最佳工具，如果你精通它的使用，那么使用其他任何东西都会非常痛苦。

使用XSLT进行维护可能会很麻烦：我最近一直在调试一个转换，它使用了大约十二个样式表的集合，这些样式表在15年的时间里变得像topsy一样，遵循逻辑是一个噩梦。有一些调试工具可以在这里提供帮助，但是对于良好的软件工程学科来说无可替代：对代码进行注释，并定期重构以保持结构清洁。这依赖于依赖于一组良好的回归测试，因此您知道您的重构是正确的。