在我的上一个camel项目中，我使用xslt将传入的xml转换为适合发送到第三方web服务的xml格式。这很好用。这仍然被认为是xml到xml映射的最佳方法吗？或者你们会推荐更好、更高性能的工具吗？
就我个人而言，我并不介意xslt，但我所在组织的其他开发人员的反馈是，他们发现很难阅读和维护，尤其是在转换相当复杂的情况下。他们说得有道理。
我正在考虑的一种替代方案是编组到java对象，并在解编组回xml之前进行转换。这样做的好处是更容易通过转换器对象进行设置和维护。然而，我担心实现这一目标所需的行动数量会对绩效产生影响。
对你的想法感兴趣。
非常感谢
虽然我同意开发人员的观点，即XSLT有点痛苦，但它并不是一个严重的痛苦。我怀疑从XML转换为POJO进行转换，然后再转换回XML将是一个性能杀手。要做的操作太多了，这种方法的O符号将是致命的。
免责声明：我不为Altova/Lquid Technologies工作
不久前，我在一家大银行工作，在那里我们使用了Altovas XML套件。他们有一个名为MapForce的产品，它将XSLT的开发和维护简化了几光年。我能够教一个没有开发经验的人如何创建有效的XSLT。这是一个非常好的产品，但有点贵。下载eval副本并对其进行旋转。
LiquidXML还有一些工具，可以让您平滑XSLT创建过程中的粗糙边缘。
我强烈建议您将这些工具视为一种选择，因为它们可能会减轻痛苦。
XSLT的主要问题是学习曲线。你已经掌握了这种语言，所以这对你来说不是问题，但对你的同事来说却是问题，他们仍然觉得这种方法奇怪和陌生。所以有点进退两难。为了减少组织中每个人都必须学习的技术总数，在工作中使用次优技术是非常值得尊敬的。不过，话虽如此，XSLT2.0无疑是这项工作的最佳工具，如果您精通它的使用，那么使用其他任何工具都会非常痛苦。
XSLT的维护可能会很麻烦：我最近调试了一个转换，它使用了大约十几个样式表的集合，这些样式表在15年的时间里像topsy一样增长，遵循逻辑有点像噩梦。有一些调试工具在这方面肯定会有所帮助，但没有什么可以替代良好的软件工程规程：对代码进行注释，并定期进行重构以保持结构整洁。这反过来又取决于是否有一组好的回归测试，以便您知道重构是正确的。