为什么选择 XSL 转换？

XSLT 是一种函数式编程语言，您可以使用它来创建与任何模板系统一样丰富的前端。但是，你不应该 - 你和你的团队会发疯。

这两个选项都提供了以逻辑方式将对象转换为演示形式的机会。XSLT 最适合于创建更多的 XML，这可能会使您认为它是用于创建 XHTML 的完美候选者。但是，创建XHTML不应该是主要目标 - 创建用户体验才是。不要关心媒介。

XSLT 的两个重要缺点与语法有关：您的模板、它们包含的模板以及这些模板包含的模板都将是巨大而冗长的。其次，你必须做大量的函数式编程，经验不足的工程师在遇到一个递归模板时，可能会感到困惑和恐惧，这个模板带有一个累积函数参数，而不是一个简单的for循环。

如果您被转换逻辑构造的有效 XML 实体的美妙之处所吸引，请考虑使用类型安全的模板系统来转换 Bean。查看Google XML Pages，并创建逻辑组织，类型安全的模板，这些模板将很容易让未来的工程师学习和扩展。

大约5年前，我为一个企业产品创建了一个XML / XSLT驱动的UI。我们仍在使用它，我现在可以回顾我的经验，看到许多优点和缺点：

优点：

• XSL是一种功能强大的声明性语言，对于有经验的开发人员来说非常有用和有趣，转换可以在几行代码中做非常惊人的事情
• XSL是为与XML一起使用而设计的，所以如果你的数据已经是XML，那么它就很有意义了。
• 关注点分离（呈现与数据）比许多模板语言更好
• 基于 XSL 的渲染可以很容易地“子类化”。我的意思是：假设您有数据类A和关联的模板A.xslt。对于从 A 派生的类 B，您可以轻松创建仅具有微小差异的 B.xslt，并包含 A.xslt 用于继承的行为。这使得它不太容易由于A.xslt的变化而断裂。
• 上述要点还为您提供了执行覆盖的能力。对于具有关联 A.xslt 的类 A，我们可以轻松地将关联的模板切换到 A-custom.xslt，这是一些小的更改加上 A.xslt 的继承。我们可以在现场即时执行此操作，同样，好处是A-custom.xslt只有几行，而不是原始A.xslt的整个修改副本。占用空间小意味着它更有可能与多个版本的A.xslt一起使用。
• 在 .NET 2.0 中，XSLT 被编译并变得非常快。Java可能有类似的技术。（大多数模板语言现在也这样做。
• 在 .NET 中，可以创建一个“对象 XPath 导航器”，它允许您转换数据对象，而不必将它们转换为 XML 对象。同样，Java中可能也有类似的技术。
• XSLT在HTML和处理转义，空白问题等方面很聪明。

缺点：

• XSL是一种强大的声明性语言，让新程序员感到困惑 - 而且很少有人知道XSLT
• XSL很详细。XML 通常也很冗长。
• XSL 转换可能比“本机”模板慢。即使编译了，XSL 的状态开销仍然比大多数模板语言多
• 很难将参数传递给 XSL，您必须根据数据发送参数（强制您创建额外的 XML）或通过系统特定方法（这可能还涉及构造 XML 数据）发送参数。
• 如果您没有 ObjectXPathNavigator 或等效项，则在将数据对象转换为 XML 进行转换时，将产生大量开销
• 根据转换器的功能，在转换为字符串缓冲区，然后将该字符串发送到输出设备时，还可能产生缓冲开销
• XSLT 使用越高级，工具支持您的可能性就越小（特别是当您开始使用包含或更快的方法来传递 XML 数据时）

我会在想到更多问题时尝试更新。我认为现在回想起来，我的决定是坚持使用通用的模板语言。当我选择 XML/XSLT 时，曾经的大问题现在已经通过主要模板引擎的更新和更成熟的修订版得到了解决。我们仍然从继承.xslt文件的能力中受益匪浅，这是大多数模板引擎都做得不好的。但最终，让大量开发人员提供示例的价值要大得多（例如，在StackOverflow上比较 ASP.NET 答案与XSLT答案。

希望有所帮助！