哪个更快，使用XSLT的XML或带有DataBinding的CLR？ 我假设它是CLR +数据绑定但我可能是错的。
答案 0 :(得分：4)
这实际上是一个非常接近我自己的问题，因为我所做的几乎所有工作都围绕着XSLT设计层，其中有一个自定义的基于.NET的后端生成数据（我喜欢系统死机）。
据我所知，有一些事情应该牢记在心：
确保使用System.Xml.Xsl.XslCompiledTransform的缓存实例。这个类使用System.Reflection.Emit来创建按需类，它将绝对快速地推出你的xslt转换
使用正确的数据结构作为xslt转换的输入。如果您有可用的XmlDocument（或更好的XPathDocument），请使用它。否则，对于非常大的输入文档和转换在xml读取器（如果可用）中传递，因为XslCompiledTransform将文档加载到XPathDocument（它们针对XPath访问进行了优化）。只是要添加，System.Xml.XPath中存在一个System.Xml.Linq.XElement类型的扩展方法，该方法将从XElement创建一个XPathNavigator，如果您的源数据结构是XElement将会派上用场
不要在xsl转换中使用msxsl：script标记。 msxsl：脚本标记的编译方式与xslt的其余部分不同，并且可能导致高需求应用程序中出现严重的内存泄漏（它们会在xslt运行时加载自定义程序集）
尽量避免使用扩展方法。我反汇编（反射器FTW）直到.NET源，用于在XSLT转换中执行扩展方法，并且它的核心实际上只是对MethodInfo.Invoke（）的调用。一些调用不会破坏你的应用程序，但不认为你可以使用扩展方法弥补XSLT的所有缺点（可能在框架的未来版本中有所改变，因为它们在自定义散列系统中缓存扩展方法，很有可能他们可以将其转换为使用编译的linq表达式，在这种情况下它会闪电般快速）
据我所知，System.Web.UI.DataBinder仍归结为System.ComponentModel.ReflectPropertyDescriptor中的一个调用，该调用使用System.Reflection.MethodInfo.Invoke（）来评估Eval（“ MyProperty“）声明。这将是两种模型之间性能最大的比较之一。通过最小化反射调用的数量，XSLT在这里占了上风。
编写未经调整的xslt文件非常容易。正确使用xsl变量可以真正消除生成xml输出所需的许多迭代。如果你有一个通常引用的输入元素，将它存储在xsl变量中，从那里访问它。
取决于您是否计划将xsl输出直接写入响应流。请记住正确调整缓冲区的大小。通过设置转换MemoryStream上的默认缓冲区大小，您可以节省大量的内存分配（在xsl转换的上下文中通常相当大）。
虽然这真的归结为应用程序级别的问题。在使用XSLT转换时，您可以避免控件创建，视图状态序列化，事件持久性等等的整个开销...创建一个更简单的页面生命周期（获取数据，转换，并在其间抛出一些细节）应该给另一个边缘到基于XSLT的系统。
总的来说，我的钱绝对是一个正确实现的XSLT转换的良好结构。特别是在具有足够RAM可用于内存转换的系统上。我已经看到XSLT转换扩展到一个相当不可思议的水平，一旦学到一些非常关键的点，它实际上并不难维护。
如果我这样做，将会看到我是否能记住任何其他人并编辑这篇文章...
答案 1 :(得分：3)
您应该对特定用例进行基准测试，而不是尝试根据错误的推广来获得（可能是错误的）答案。