XSLT 与 XMLDocument 数据类型 ->使用 foreach -> 循环遍历节点附加到文字控件
我有一个关于使用 .NET 框架在 C# 中设置 XML 样式的问题。我正在开发一个网站，该网站 99% 的数据都存储为 XML。很多时候，我要么使用 XSLT 来转换此 XML，要么将 XML 读取为 XMLDocument 数据类型，使用 XPATH 对其进行解析，然后基本上将输出附加到整个页面的 Literal 服务器控件中以处理显示。 我有一种感觉，后者在内存方面要昂贵得多，因为我将 XML 读入数据类型并使用 foreach 语句和其他逻辑语句循环遍历节点。我通常这样做的唯一原因是因为我更愿意这样做，并且因为我绝不是 XSL 专家，所以这是我完成我需要做的事情的唯一方法。 我想我想知道是否有人知道这样做更要贵多少？除了我正在解析的 xml 的大小之外，还有哪些因素可能会影响这一点。先感谢您。
I have a question regarding styling XML in C# using the .NET framework. I'm working on a web site that has 99% of it's data stored as XML. Quite often, I'm stuck to either using an XSLT to transform this XML, or reading the XML into an XMLDocument data type, parsing through it using XPATH, and basically appending the output into Literal server controls throughout the page to handle the display.
I have a feeling that the latter is much more expensive in terms of memory, as I'm reading the XML into a data type and looping through the nodes with foreach statements and other logical statements. The only reason I typically do this is because I'm much more comfortable doing it this way, and because of I am by no means an XSL guru, it's the only way I can get done what I need to do.
I guess I wanted to know if anyone knows just how much more expensive it is doing it that way? And what factors might influence that besides the size of the xml I'm parsing through. Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了马克的回答之外，还有其他一些事情需要考虑；
您的 xslt 文件可以独立于重新编译代码进行编辑。我开发了一个与您所描述的类似的系统，并且独立于更改代码来部署转换的能力非常有用；必须重新编译和重新部署所有二进制文件比部署单个 xslt 更困难。
Xslt 到 HTML 比 XML 解析、文字和大量后面设置文字等的代码的组合要干净得多。xslt 可以有效地成为输出 HTML。
Xslt
另一方面，尤其是 2，您将失去 asp.net 可以提供的许多强大功能，从 Web 表单到 MVC。考虑到您最终想要填充一个 asp.net 服务器控件，您这样做的方式很好，否则您运行 xslt 只是为了获取值 - 这并不是 xslt 的真正用途（它将 XML 从一种结构到另一种结构）。
就性能而言，您是对的，XML 的大小很重要。如果您有 200 个用户，每个用户都加载一个 10mb 的 XML 文档，并且大约在同一时间执行此操作，那么您可以看到数据方面的开销。但如果是同一个 XML 文档，则加载一次。事实上，如果可能的话，缓存转换或处理的结果。
Xslt 处理大多是轻量级的。不正确的情况是 xslt 使用外部函数或大量递归，从而生成大型输出文档。
然而，有时，DOM 样式处理比 xslt 容易得多，因为您可以更简单地传递变量，可以使用 .Net BCL 函数等进行更多处理。在这种情况下，值得使用 XMLDocument 和 C# 代码，因为它更简单。
所以这确实取决于。
请记住，如果您怀疑某些东西效率不高，那么尝试一些东西然后对其进行分析总是值得的。这将帮助您计算出实际成本是多少。有时，这是决定某件事是否是“最佳”方式的唯一方法。
In addition to Marc's answer, there are a couple of other things to think about;
Your xslt files can be edited independently of recompiling the code. I worked on a similar system to what you are describing, and the ability to deploy the transformations independently of changing the code was useful; having to recompile and redeploy all of the binaries was a more difficult task than deploying a single xslt.
Xslt to HTML can be a lot cleaner than a combination of XML parsing, literals and lots of code behind to set the literals etc. The xslt can effectively be the output HTML.
On the other hand, with 2 especially, you are then losing out on many of the great features that asp.net can offer, from web forms through MVC. Given that you eventually want to populate an asp.net server control, the way you are doing it is fine, as otherwise you are running xslt just to get values out - which isn't really what xslt is for (which is transforming XML from one structure to another).
In terms of performance, you are right, the size of the XML is important. If you have 200 users and they each load a 10mb XML document, and they do it around the same time, then you can see what the overhead is just in terms of data. If it's the same XML document, though, load it once. In fact, cache the results of the transformation or processing, if possible.
Xslt processing is mostly lightweight. Situations where this isn't true is when the xslt uses external functions or is heavily recursive, producing large output documents.
However, sometimes, DOM style processing is much easier than xslt as you can pass around variables more simply, can do more processing using .Net BCL functions etc etc. in this instance, it's worth using XMLDocument and C# code just because it's simpler.
So it really does depend.
Remember, it's always worth trying something then profiling it if you suspect it isn't efficient. This will help you work out what the costs really were. Sometimes this is the only way to decide if something is the "best" way.
之前已经展示过，如Jon Bentley 的经典书籍在 Assembler 中实现的糟糕算法的执行速度比在 Basic 中实现的好算法慢数千倍。
因此，“技术 A 比技术 B 更快”的说法是完全错误的。
至于消耗的内存，很大程度上取决于 XML 文档的大小。 XmlDocument 和典型的 XSLT 1.0 或 2.0 处理器都在内存中构建完整 XML 文档的表示，因此在这两种情况下处理多 GB 的 XML 文档都是有问题的。
XSLT 3.0（仍处于工作草案状态）有一个流功能，允许以流模式处理 XML 文档这转换中使用的 XPath 表达式遵循某些限制。
我认为考虑一组指标而不是仅考虑单个指标会很有用。
XSLT 是一种专门为处理树结构而设计的语言，因此它提供了其他语言中不存在的有价值的功能。两个例子是模板和模式匹配。
使用模板和模式匹配可以以声明方式表达转换。代码更简单、更短、更容易理解和维护、可扩展。与使用过程语言编写类似意大利面条的过程性代码相比，编写 XSLT 代码通常只需几分钟即可完成。
由于变量是不可变的，所以用函数式语言调试程序甚至正确性证明都容易得多。
由于同样的原因，XSLT 处理器进行非常积极的优化的可能性更大。
最后，让我反驳一下@dash 原本很好的答案中的一个说法：
实际上，有一种编写 XSLT 的风格，其中内容和处理之间有严格而清晰的分离（我称之为填空< /em> 模式）。
例如，请参阅我对此问题的回答。
以下是使用这种方法开发 XSLT 应用程序的一些优点：
此代码可以使用任何数据文档中的数据（同样作为外部参数传递的路径）来填充任何呈现文档（作为外部参数传递的路径）外部参数）。因此，可以创建填充不同数据的不同输出/格式。
要替换为“实时内容”的占位符（
gen:data元素）可以具有不同的格式和语义 - 想象力不受限制。编辑者（非 XSLT 专家）可以独立于 XSLT 开发人员处理一个或多个呈现文档。
实现了更高程度的可重用性、灵活性和可维护性。
总结：使用基于 DOM 的过程语言转换 XML 的方法虽然可行，但开发资源成本更高，并且代码复杂性、可理解性、可维护性和可扩展性方面质量较差。
It has been shown before, as in Jon Bentley's classic book that a bad algorithm implemented in Assembler executes many thousands of times slower than a good algorithm implemented in Basic.
Therefore, it is simply incorrect to say that "technology A is faster than technology B".
As for the memory consumed, it is largely dependent on the size of the XML document(s). Both XmlDocument and a typical XSLT 1.0 or 2.0 processor build a representation of a complete XML document in memory, therefore working with multi-gigabyte XML documents is problematic in both cases.
XSLT 3.0 (still in a Working Draft status) has a streaming feature that allows to process an XML document in streaming mode provided the XPath expressions used in the transformation adhere to certain restrictions.
I believe that it is useful to consider a set of metrics vs only a single one.
XSLT is a language designed especially for processing tree stuctures and as such it offers valuable features that aren't present in other languages. Two examples are templates and pattern matching.
Using templates and pattern matching it is possible to express a transformation declaratively. The code is much more simpler, shorter, easier to understand and maintain, extensible. Writing XSLT code typically can be done in minutes compared to many hours of coding procedural, spagheti - like code in a procedural language.
Debugging a program in a functional language and even proof of correctness is much easier due to the fact that variables are immutable.
Due to the same reason there are much greater possibilities of very aggressive optimization by the XSLT processor.
Finally, let me rebute a statement made in the otherwise good answer of @dash:
Actually, there is a style of writing XSLT, where there is a strict and clean separation between content and processing (I call this the fill-in the blanks pattern).
See for example, my answer to this question.
Here are some advantages of developing an XSLT application with this approach:
This code can populate any rendering document (path passed as an external parameter) using the data from any data document (again path passed as an external parameter). Thus it becomes possible to create different outputs/formats populated with different data.
The placeholders (
gen:dataelements) to be replaced with "live content" can have different format and semantics -- no limits to one's imagination.Editors (non-XSLT experts) can work on one or more rendering documents independently from each other and from the XSLT developers.
A higher degree of reusability, flexibility and maintainability is achieved.
To summarize: The approach of transforming XML with a DOM-based procedural language, while possible, is more costly in terms of development resources and results in lesser quality in terms of code complexity, understandability, maintainability and extensibility.
Xslt 的工作原理相同；它将其加载到 DOM 中（尽管通常不是 XmlDocument - 有一个更轻量级的只读模型可用 - XPathDocument），并执行 xpath 表达式（最终，在节点上循环）。
写得不好的 xslt 可能会很慢，写得不好的 c# 可能会很慢。要知道哪个更快，您需要进行分析，并注意也可以简单地改进您当前的代码（无论哪种）。
Xslt works on the same principal; it loads it into a DOM (although typically not XmlDocument - there is a lighter-weight read-only model available - XPathDocument), and executes xpath expressions (ultimately, looping over nodes).
Badly written xslt can be slow, and badly written c# can be slow. To know which is faster you'll need to profile, noting that it may also be possible to simply improve your current code (no matter which).