XmlNode не поддерживается в Silverlight: повторно реализовать или использовать синтаксический анализ строк?
Я написал приложение WPF, которое хочу перенести на Silverlight 2.
Моя бизнес-логика и модель (для шаблона проектирования M-V-VM) упакованы в отдельную сборку, которую я пытаюсь преобразовать в библиотеку классов Silverlight.
К сожалению, класс XmlNode, который я использую для синтаксического анализа XML-файла с данными модели, не поддерживается Silverlight 2. Вместо этого рекомендуется использовать LING to XML (http://silverlight.net/forums/t/14577.aspx). Использование LINQ кажется мне излишним для моей задачи. Я рассматриваю возможность замены кода синтаксического анализа XML с использованием XML DOM схемой, основанной на регулярных выражениях (для анализа атрибутов). В качестве альтернативы я подумываю написать свою собственную реализацию XmlNode, на которую будет ссылаться в случае, если проект был скомпилирован для Sliverlight 2.
Кто-нибудь сталкивался с подобной ситуацией? Есть ли у кого-нибудь предложения (возможно, третий вариант) о том, как действовать (RegEx или переписать)?
Ответы 2
Не уверен, что Linq to Xml является излишним. На самом деле, с Linq2xml намного проще выполнять синтаксический анализ XML, как только вы освоите его. Я бы сказал, что регулярное выражение или написание собственного XmlNode было бы излишним.
Если вы опубликуете какую-то работу XmlNode, которую вы делаете, я уверен, что вы получите хорошие переводы. А пока вот хорошее введение того, насколько легко анализировать документы с помощью Linq to Xml.
Обновлять: В ответ на то, что проблема связана с производительностью, все, что я смог найти, это то, что linq в xml больше Быстрее, чем XmlDocument.
Если у вас нет действительно причудливого сценария, любые накладные расходы от методов LINQ довольно незначительны. Я определенно рекомендую пойти с этим, вместо того, чтобы выполнять весь синтаксический анализ вручную.
Класс System.Xml.Linq содержит классы XML DOM, такие как XDocument, XElement, XNode и XAttribute, которые являются более производительными и легкими по сравнению с их счетными частями XmlDocument, XmlElemnt и т. д. Вы можете использовать эти классы без использования Linq, но с Linq to Xml вы можете делать очень интересные вещи. Это абсолютно правильный путь!
Я должен был быть более конкретным. Меня беспокоят накладные расходы на производительность при использовании LINQ2XML по сравнению с простым настраиваемым анализатором. LINQ будет использовать отражение для создания экземпляров анонимных типов. Например, пользовательский код создает экземпляры напрямую.