App.config по сравнению с .ini файлами
Я рассматриваю проект.NET, и я столкнулся с некоторым довольно тяжелым использованием .ini файлов для конфигурации. Я очень предпочел бы использовать app.config файлы вместо этого, но прежде чем я вскочу и сделаю проблему из этого с devs, интересно, существуют ли какие-либо допустимые причины способствовать .ini файлам по app.config?
3 ответа
Ну, в среднем .INI-файлы, вероятно, более компактны и в некотором смысле более удобочитаемы для людей. XML немного неудобно читать, и он довольно многословен.
Однако app.config, конечно же, является стандартным механизмом конфигурации .NET, который поддерживается в .NET и имеет множество ловушек и способов что-то делать. Если вы используете файлы .INI, вы, по сути, «полностью катаетесь самостоятельно». Классический случай «изобретения велосипеда».
И снова: есть ли шанс, что это проект, который начал свою жизнь до .NET? Или порт существующего приложения для Windows до .NET, где файлы .INI были подходящим вариантом?
По сути, в файлах .INI нет ничего плохого - они просто больше не поддерживаются в .NET, и вы сами можете расширять их, обрабатывать их и т. Д. вам когда-либо понадобится помощь извне - вряд ли какой-либо .NET-разработчик столкнется с файлами .INI, в то время как система конфигурации .NET довольно широко известна и понятна.
Лично я никогда не использую .ini /xml файлы конфигурации для чего-то большего, чем загрузка всех значений в синглтон или что-то подобное, а затем использую их во время выполнения, как это...
Учитывая это, я твердо убежден, что вам следует обратить внимание на тип данных и их использование. Если данные находятся в контексте приложения в плане настроек и конфигураций, то я считаю, что файл app.config является правильным местом для хранения этих настроек.
Если, с другой стороны, данные касаются загрузки проектов, изображений или других ресурсов, связанных с содержанием приложения, то я считаю, что .ini (кто-нибудь использует .ini файлы? Я думаю о .xml файле для хранения этой информации). Короче говоря: сегментируйте содержимое хранимых данных в соответствии с доменом и контекстом.
Ini-файлы вполне подходят для моей книги. Проблема в GetPrivateProfileString () и кузинах. Appcompat превратил это в уродливую придурку функции API. Получение одного значения ini занимает около 50 миллисекунд, что на современном ПК - это гора времени.
Но самая большая проблема в том, что вы не можете контролировать кодировку INI-файла. Windows всегда будет использовать системную кодовую страницу для интерпретации строк. Это нормально, только если ваша программа не уходит далеко от вашего рабочего места. Если это так, существует серьезный риск получения тарабарщины, если вы не ограничиваете набор символов, используемый в вашем INI-файле, до ASCII.
XML не имеет этой проблемы, он хорошо поддерживается платформой .NET. Независимо от того, используете ли вы настройки или управляете своей конфигурацией самостоятельно.