Tat*_*ato 2 xml data-binding xslt xml-serialization
使用XSLT的XML或带数据绑定的CLR，哪个更快？我假设这是CLR +数据绑定，但是我可能是错的。
这实际上是一个非常贴心的问题，因为我所做的几乎所有工作都是围绕XSLT设计层展开的，这些层具有一个基于自定义.NET的后端来生成数据（我爱死了系统）。
据我所知，应牢记以下几点：
绝对确保使用System.Xml.Xsl.XslCompiledTransform的缓存实例。此类使用System.Reflection.Emit创建按需类，这些类将绝对快地以惊人的速度输出xslt转换
使用正确的数据结构作为xslt转换的输入。如果您有可用的XmlDocument（或更好的XPathDocument），请使用它。否则，对于非常大的输入文档和转换，请传递xml阅读器（如果可用），因为XslCompiledTransform会将文档加载到XPathDocument中（针对XPath访问进行了优化）。只需添加一下，System.Xml.Linq.XElement类型的System.Xml.XPath中就有一个扩展方法，该方法将从XElement创建XPathNavigator，如果您的源数据结构是XElement，该方法将派上用场
不要在xsl转换中使用msxsl：script标记。msxsl：script标记的编译方式与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转换的良好结构上进行的。尤其是在具有大量内存可用于内存转换的系统上。我已经看到XSLT转换的规模达到了令人难以置信的水平，并且一旦掌握了一些非常关键的点，维护起来实际上并不难。
会看看我是否还能记得其他人，如果可以的话会编辑这篇文章...