Собственная обработка Xml или (внешняя) библиотека

У меня есть несколько проектов с разными конфигурациями, все эти конфигурации должны быть указаны в одном файле XML. Это не app.config, а указано в общем местоположении.

Моя текущая структура проекта:

  • основной проект (с некоторым XML)
  • подпроект (необходим общий доступ к основной конфигурации XML + собственная конфигурация из того же XML-файла)

Какая технология .NET XML лучше всего подходит для этого?

заранее спасибо


c# xml-deserialization
person mrtentje    schedule 11.04.2013    source источник
comment
Я бы также предложил переименовать заголовок сообщения во что-то вроде обработки Native Xml или внешней библиотеки, C # не нужен в заголовке, поскольку тег уже есть, и ваш текущий заголовок не совсем точно отражает содержание сообщения на данный момент.   -  person Wim Ombelets    schedule 11.04.2013
comment
Я бы использовал Linq To Xml ...   -  person I4V    schedule 11.04.2013

Ответы (3)


arrow_upward
1
arrow_downward

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

Я работаю с Xml почти ежедневно, и мне пока не нужны никакие внешние библиотеки. Конечно, все зависит от требований вашего проекта, но у вас есть два проекта, которые будут использовать одну и ту же функциональность, поэтому вы можете (и должны) легко сделать абстракцию и изоляцию обработки Xml для обоих проектов, либо ссылаясь на свое собственное ядро\ xml в подпроекте или (мое предпочтение) в отдельном проекте dll. DLL может сослужить вам хорошую службу в будущем.

Дополнительным бонусом к написанию собственной функциональности Xml является то, что вы получаете более глубокие знания о внутренней работе пространства имен .Net Xml, знания, которые никоим образом не пропадают даром, в то время как вы бы дистанцировались от него, используя внешние библиотеки (которые часто являются не более чем оболочками и фасадами для классов .Net)

Надеюсь, что это несколько полезно и счастливое кодирование.

person Wim Ombelets    schedule 11.04.2013

arrow_upward
1
arrow_downward

Файл app.config, вероятно, лучше всего подходит для этого. Вы можете создавать свои собственные разделы конфигурации, а единый файл конфигурации для проекта доступен для всех сборок, на которые ссылаются, поэтому каждая сборка может иметь свой собственный раздел. У вас также может быть специфичная для пользователя конфигурация в user.config (см. Архитектура параметров приложения).

Если вы не можете использовать app.config, потому что он должен находиться в определенном месте, вы всегда можете загрузить файл app.config из другого места с помощью ConfigurationManager.OpenMappedExeConfiguration.

Другие альтернативы:

  • Используйте XmlSerializer для десериализации XML в POCO с вашей конфигурацией.
  • Мазохистский вариант: используйте простые XDocument или XmlDocument для ручного анализа файла конфигурации на лету.
person Eli Algranti    schedule 11.04.2013

arrow_upward
0
arrow_downward

Актуальное решение проблемы:

С помощью LINQ to XML я беру элемент XML, соответствующий объекту. Этот элемент XML ниже на один уровень глубже, чем корень. Таким образом, я сначала «фильтрую» корневые теги, а затем преобразую их в строку в объекты с десериализацией.

Например

<root>
    <project1>
       <somevalue>myvalue</somevalue>
    </project1>
    <project2/>
</root>

Если бы я хотел все из проекта1, я получаю строку с потомками с помощью LINQ to XML, а затем десериализую строку в соответствующий объект (объекты).

person mrtentje    schedule 11.04.2013