Альтернатива сериализации XML для конфигурации - PullRequest
Новая
       23

Альтернатива сериализации XML для конфигурации

5 голосов
/ 01 июля 2010

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

Я хотел бы использовать встроенный файл app.config, но он, похоже, не поддерживает собственные классы. Например, с сериализацией XML я могу легко сериализовать универсальный list<ComplexClass> без дополнительного кода. Это просто работает. Кажется, что при использовании app.config, вы должны предоставить массу информации и пользовательских классов, чтобы это работало. Кроме того, большинство учебных пособий по "пользовательской конфигурации" относятся к 2007 году и могут быть устаревшими, насколько мне известно. У кого-нибудь есть информация о самом последнем способе сделать это в .NET 4.0?

Кроме того, когда в приложении возникает проблема, 9/10 раз это происходит из-за неправильной конфигурации. App.config любит хранить изменяемые пользователем настройки в очень недоступном месте для пользователей, которые не знакомы со скрытыми каталогами и тому подобным. Есть ли способ иметь единственное место для хранения файла конфигурации, который пользователь может легко отправить нам по электронной почте, когда возникнет проблема?

Или все это проще, чем я помню, в первые 2,0 дня? Любые ссылки или быстрые примеры того, как легко сделать пользовательскую информацию app.config, были бы хороши.

В качестве дополнительного примера, это урезанная версия одного из типов объектов, которые я хочу сериализовать как List<Alarm>, так как количество Alarm s может варьироваться или быть пустым. Есть ли аналогичный способ сохранить что-то подобное в app.config? 

[Serializable]
public class Alarm
{
    [Serializable]
    public class AlarmSetting
    {
        public enum AlarmVariables { Concentration, RSquared }
        public enum AlarmComparisons { LessThan, GreaterThan }

        [Description("Which entity is being alarmed on.")]
        public AlarmVariables Variable { get; set; }
        [Description("Method of comparing the entity to the setpoint.")]
        public AlarmComparisons Comparator { get; set; }
        [Description("Value at which to alarm.")]
        public Double Setpoint { get; set; }
    }

    public String Name { get; set; }
    public Boolean Enabled { get; set; }
    public String Parameter { get; set; }
    public List<AlarmSetting> AlarmSettings { get; set; }
    public System.Drawing.Color RowColor { get; set; }
}

Ответы [ 4 ]

7 голосов
/ 01 июля 2010

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

ИМХО, настройки конфигурации не должны быть контейнером по умолчанию для пользовательских настроек.Для меня есть файл конфигурации, чтобы убедиться, что приложение работает в данной среде.Например, для определения строк подключения, частоты опроса или подобных вещей.

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

В приведенном вами примере один из способов настройки того, что кажется одним или несколькими аварийными сигналами:прекрасный пример того, что принадлежит таблице базы данных.

2 голосов
/ 01 июля 2010

В течение многих лет я использовал сериализацию XML, аналогичную описанной вами, в ряде различных проектов.Если вы не хотите откусить SQL для настройки, это, кажется, лучшее решение.

ИМХО, механизм app.config ничем не лучше прямой XML-сериализации.На самом деле сложнее получить доступ к этой конфигурации из разных проектов.Если вы сохраняете только переходное состояние (пользовательские параметры и т. Д.) Из приложения WinForms, тогда настройки приложения могут быть удобны для простых типов данных.

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

Если вы не пишете этот файл много Я бы скептически отнесся к повреждению файлаиз-за перебоев в подаче электроэнергии.

1 голос
/ 23 ноября 2013

Поскольку в 2007 году мы приняли решение отказаться от использования Microsoft Configuration System, мы ни на секунду не пожалели.

Взгляните на это: http://blog.aumcode.com/2013/08/aum-configuration-as-facilitated-by-nfx.html

1 голос
/ 01 июля 2010

Если вы не можете отследить источник ошибки, вы только предполагаете, что она имеет какое-либо отношение к файлам XML.Вполне возможно, что встроенный XmlSerializer не работает .. например, у вас может быть циклическая ссылка где-то, но трудно комментировать, если вы не знаете, в чем ваша ошибка.

Иногда использование встроенного сериализатора Xml не лучший выбор, и когда объекты становятся сложными, может быть лучше выполнить сериализацию и десериализацию самостоятельно.Вы получите больший контроль и сможете более точно определять / восстанавливать неверные данные файла.

XDocument doc = new XDocument(
    new XElement("attachments",
        new XElement("directory", attachmentDirectory),
        new XElement("attachment-list",
            from attached in attachedFiles
            select new XElement("file", 
                new XAttribute("name", attached.FileName), 
                new XAttribute("size", attached.FileSize))
            )
        )
    );

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

...