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