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

Question

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

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

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

Какая технология .NET XML подходит для этого?

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

Answer 1

В настоящее время решение проблемы:

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

Например

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

• использования XmlSerializer для десериализации XML в POCO с вашей конфигурацией.
• Мазохистский вариант: используйте простой XDocument или XmlDocument, чтобы вручную проанализировать конфигурационный файл на лету.