Должен ли XML-файл содержать <Count>узлов, которые могут быть получены? - PullRequest
Новая
       3

Должен ли XML-файл содержать <Count>узлов, которые могут быть получены?

0 голосов
/ 28 сентября 2010

В настоящее время я работаю с большим XML-файлом, который включает <Count>123</Count> для некоторых элементов и не имеет их для других. Например: 

<Animals>
  <Pigs>
    <Pig ...>
      ...
    </Pig>
    <Pig ...>
      ...
    </Pig>
    <PricePerPound>13<PricePerPound>
    <Count>2</Count>
  </Pigs>
  <Chikens>
    <Chicken ...>
      ...
    </Chicken>
    <Chicken ...>
      ...
    </Chicken>
    <PricePerPound>12<PricePerPound>
    <!-- No Count -->
  </Chickens>
  ...
</Animals>

Итак, фактический файл намного сложнее и не имеет ничего общего с животными. Я просто не буду раскрывать все детали. Файл загружается один раз при запуске и сохраняется один раз при выходе, его вес составляет от 2 до 5 мегабайт, в зависимости от содержимого.

С одной стороны, наличие <Count> потенциально может немного увеличить время загрузки, но, возможно, нет. С другой стороны, это значение не является необходимым, оно является производным, и не дай Бог, оно отклоняется от того, что должно было быть. Возможно, не так много работы для вычисления / извлечения количества узлов с определенным именем (обратите внимание на узел <PricePerPound> - он может испортить счет, если игнорировать имена узлов). У меня нет особой гибкости при перепроектировании XML, плюс было бы слишком много работы. Добавление или удаление <Count> везде было бы большой работой (вся эта громоздкая логика, которая читает и записывает части XML ...), но сейчас я хочу выбрать подход на будущее, чтобы я мог сделать это в приращениях.

Итак, какой путь кажется лучше - добавлять или удалять <Count> везде, или, возможно, сделать его необязательным, и написать его в «Сохранить», и в конечном итоге сделать его обязательным, или что-то еще?

1 Ответ

1 голос
/ 28 сентября 2010

Если для этого нет веских причин для производительности, я бы согласился, что это плохое проектное решение, и проголосовал бы за его удаление из структуры - его можно легко рассчитать и испортить.

...