Преимущества XSLT или Linq к XML
Извините, если это уже освещено, но просто иметь вкладку «изменения» там, где я могу видеть свои локальные изменения, входящие изменения, удаленные изменения - просто то, без чего я не могу жить… В Eclipse я могу » не могу найти такую особенность!
Также просто простая вещь, такая как средний щелчок, который привязывается к «открытому объявлению», является отличным дополнением пользовательского интерфейса - то, что я также не могу увидеть реализованным в Eclipse.
На моем рабочем месте есть только «Затмение», но я серьезно думаю о покупке персональной лицензии на «Идею» ...
5 ответов
Без дальнейшего знания вашего варианта использования трудно дать вам общие рекомендации.
Так или иначе, вы несколько сравниваете яблоки и апельсины. LINQ to XML (и LINQ в целом) - это язык запросов, тогда как XSLT - это язык программирования для преобразования древовидной структуры XML. Это разные концепции. Вы можете использовать язык запросов всякий раз, когда хотите извлечь определенную часть информации из источника данных, чтобы делать с ней все, что вам нужно (будь то установка полей в объекте C #). Напротив, преобразование было бы полезно для преобразования одного XML-представления ваших данных в другое XML-представление.
Итак, если ваша цель состоит в создании объектов C # из XML, вы, вероятно, не захотите использовать XSLT, но любой из другие технологии, предлагаемые .NET Framework для обработки XML-данных: старый XmlDocument , XmlReader , XPathDocument , XmlSerializer или XDocument . У каждого из них есть свои преимущества и недостатки, в зависимости от размера ввода, сложности ввода, желаемого вывода и т. Д.
Поскольку вы имеете дело только с HTML, вы можете также ознакомиться с HTML Agility Pack на CodePlex.
Поскольку вы переходите на C #, в какой-то момент ваши данные все равно будут проходить через Linq (или какой-либо другой XML-код для .NET), вы также можете все это вставить.
Если у вас нет веских причин для перехода на XSLT, например, у вас уже есть большой опыт или развертывание настоятельно поддерживает развертывание текстовых файлов, храните все это в одном месте.
Вам не следует использовать , если вы просто пытаетесь разобрать HTML. HTML! = XML и не может обрабатываться одинаково. Например, escape-последовательность "& nbsp;" совершенно корректно в HTML, но не является действительным объектом в допустимом XML-документе (без серьезной возни с DTD и т. д.). Это вас укусит, поверьте!
Я бы также рекомендовал использовать HTML Agility pack - отличную библиотеку.
По моему опыту, XSLT более краток и удобочитаем, когда вы в основном имеете дело с переупорядочиванием и выбором существующих xml-элементов. XPath короткий и простой для понимания, а синтаксис xml позволяет избежать засорения вашего кода операторами XElement и XAttribute . XSLT отлично работает как язык преобразования xml-дерева .
Однако у него плохая обработка строк, неинтуитивный цикл и отсутствует осмысленная концепция подпрограмм - вы не можете преобразовать вывод другого преобразования .
Итак, если вы действительно хотите возиться с содержимым элементов и атрибутов, то это быстро не удается. Между прочим, нет проблем с использованием обоих - XSLT для нормализации структуры (скажем, чтобы гарантировать, что все элементы table имеют tbody элементов), и linq-to-xml для его интерпретации. Возможности условного сопоставления с приоритетом означают, что XSLT легче использовать при работе со многими похожими, но разными совпадениями. Xslt хорош в упрощении документов, но в нем просто отсутствует слишком много базовых функций, чтобы быть достаточным самим по себе.
Искренне вскочив на подножку Linq-to-Xml, я бы сказал, что он меньше пересекается с XSLT это может показаться на первый взгляд. (И мне бы очень хотелось увидеть реализацию XSLT 2.0 / XQuery 1.0 для .NET.)
Что касается производительности, обе технологии работают быстро. Фактически, поскольку так сложно выразить медленные операции, вы вряд ли случайно вызовете медленный регистр в XSLT (если вы не начнете играть с рекурсией ...). Напротив, Возможности LINQ to Xml также могут замедлить его: просто используйте любой тяжелый объект .NET во внутреннем цикле, и у вас возникнут проблемы с производительностью.
Что бы вы ни делали, не пытайтесь злоупотреблять XSLT, используя его. для выполнения чего угодно, кроме простейшей логики: он более многословен и гораздо менее читабелен, чем эквивалентный C #. Если вам нужна куча логики (даже такие простые вещи, как date> DateTime.Now? "Будет": "имеет" стало огромным раздутым хаком в XSLT), и вы не хотите использовать одновременно XSLT и Linq в Xml, используйте Linq.
date> DateTime.Now? "Будет": "имеет" стало огромным раздутым хаком в XSLT), и вы не хотите использовать одновременно XSLT и Linq в Xml, используйте Linq. гораздо более многословен и менее читаем, чем эквивалентный C #. Если вам нужна куча логики (даже такие простые вещи, как date> DateTime.Now? "Будет": "имеет" стало огромным раздутым хаком в XSLT), и вы не хотите использовать одновременно XSLT и Linq в Xml, используйте Linq.