Что делать с именами узлов XML (жестко закодированными значениями)?

В последнее время я работаю с xml. И заметил небольшое явление (может быть, не такое уж большое дело для остального мира, но для меня это было). Возможно, это я новичок. Но разве большинство жестко запрограммированных или магических чисел не следует выносить в файл конфигурации? Например,

    string url = "http://www.domain.com/aDocument.xml";        
    XmlDocument feed = new XmlDocument();
    feed.Load(url);

    XmlNode errorsNode = feed.SelectSingleNode("Errors");

    if (errorsNode != null)
    {
        XmlNode error = errorsNode.FirstChild;
        lblError.Text = "Error: " + error.SelectSingleNode("Code").InnerText;
    }

Вот xml-документ:

  <Errors>
    <Error>
        <Code>AWS.MissingParameters</Code>
        <Message>You are missing an parameter</Message>
    </Error>
 </Errors>

Как бы вы разобрали это без жесткого кодирования «кода» или «сообщения»?


person kevindaub    schedule 19.02.2009    source источник


Ответы (2)


Так же, как и для чисел. Я бы объявил константы строкового типа, у которых есть имя элемента, который нужно получить, а затем передал бы его методам в моих инструментах XML.

Однако вы можете захотеть создать представление объекта из XML-документа (или схемы, если она у вас есть), которая будет обрабатывать все это за вас. Таким образом, вы можете просто загрузить XML-документ в код, и он выполнит для вас синтаксический анализ в объектном представлении.

Затем, если XML изменится, вы должны изменить сгенерированный код, чтобы использовать ваши новые имена элементов.

Для этого вы хотите использовать инструмент XSD.EXE.

person casperOne    schedule 19.02.2009

Я не знаю, является ли это лучшим вариантом, но я обычно видел, как подобные вещи обрабатываются с помощью набора строковых констант. По крайней мере, если вы обрабатываете одну и ту же XML-схему в нескольких местах, все ваши магические строки определяются в одном месте. Я думаю, что передача этого в файл конфигурации будет излишним, если только схема не будет часто меняться.

person Mike Powell    schedule 19.02.2009