Здравствуйте,
Как известно большой минус хранить настройки в приложении
в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Пробовал для конфигов использовать s-expression формат(несколько приложений/несколько лет уже работают с таким конфигом оК): https://github.com/ichensky/S.NET
удобно, можно писать комментарии, конфиг получается компактным, легко читаемым/редактируемым.
;;; This app ...
(app (name "Cool app")
(connectionString "db=;user=;pass;") ;; Connection string to db
(oneMoreProp "..."))
Но, что если вместо конфигов сразу использовать C# код? Просто обычный C# класс
public class Config {
public const string Name = "Cool app";
public const string ConnectionString = "db=;user=;pass;";
}
Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению.
Какие минусы по сравнению с тем же json/xml?
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
Комментарии есть.
J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Верно. Но есть в .net парсер настроек из "json" который понимает не вполне нормальный json, а именно — поддерживает комментарии!
J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению. J>Какие минусы по сравнению с тем же json/xml?
Я не понял. Файл компилируется сразу в проекте или динамически добавляется при старте приложения?
Если первое, то нет возможности сменить настройки после старта, что наиболее важно для файла настроек
Если второе, то нет навигации по коду и рефакторинга, зато синтаксис не особо удобный для настроек.
Здравствуйте, #John, Вы писали:
J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии.
В XML как раз писать комментариев можно сколько угодно. Так же плюс — конфиг может быть структурным.
J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Можно использовать парсер который позволяет и комментарии и висячую запятую, тот же ньютонсофт.
J>Пробовал для конфигов использовать s-expression формат(несколько приложений/несколько лет уже работают с таким конфигом оК)
Это лиспоидный ужас. Обилие скобок только усложняет. По сути те же трудности, что и в XML, только в ином синтаксисе. Ужас тут, не в как таковом решении, а в его крайней не популярности.
J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению. J>Какие минусы по сравнению с тем же json/xml?
Этот параграф абсолютно применим к любому формату файла. Нюансы будут только в конечных инструментах, но нет ничего, что бы не делалось.
Кроме того, маппинг как таковой и валидация настроек вещи разные. Если связь идет банально по названием ключей — то отсутствующие опции должны быть замечены именно валидацией, и выявлены в непродолжительное время. Есть подозрение, что это вообще не является проблемой, т.к. опций не так и много. Если их много — тогда XML со схемой или json со схемой могут быть лучшими решениями, т.к. поддерживаются редакторами, валидируются в какой-то мере.
Так же есть старые добрые ini-файлы на любой вкус. Максимально просто формат, в него укладываются довольно много вещей и он так же всем понятен и легко читается как пользователями так и машиной.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, J>Как известно большой минус хранить настройки в приложении J>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии. J>в json: нет возможности писать комментарии, надо постоянно то вставлять, то удалять запятую что бы разделить поля.
Это почему в JSON нельзя вставлять коментарии? Json.NET прекрасно читает JSON с многострочными и однострочныси коментариями.
Здравствуйте, Danchik, Вы писали:
D>Это почему в JSON нельзя вставлять коментарии?
Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.
Douglas Crockford написал пост, почему он решил не добавлять коменты в json, но все ссылки ведут на google++ который сдох.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, #John, Вы писали:
J>>в xml: файл с настройками получается плохо читаемым, нет возможности писать комментарии. F>Комментарии есть.
Есть, но они сильно ограничены, потому что напр. нельзя закомментировать любой аттирибут в средине тега,
нельзя написать комментарий возле аттрибута в теге.
F>Я не понял. Файл компилируется сразу в проекте или динамически добавляется при старте приложения? F>Если первое, то нет возможности сменить настройки после старта, что наиболее важно для файла настроек
Выше в комментарии там поля должны быть обычными, а не `const`, так что можно будет после старта приложение переопределить их.
А если нам надо загружать разные настройки для разных envitorments(пароли/приватные ключи), то можно такие настройки вынести в под конфиг
напр. структуру проекта:
Теперь если мы запускаем `./build.sh dev` (с ключем `dev` напр.),
и скрипт сделает билд проекта `src/my_app` в дерикторию `./package/usr/bin/my_app` ,
скопирует `./etc/` в `./package/`
а потом скопирует(с оверайдом) все файлы из дериктории `/env/dev/`
и успешно перезапишет `./package/etc/my_app/keys_config.cs`
После установки пакета, приложение после запуска прочитает сначала конфиг `/etc/my_app/config.cs`, а потом динамический из `/etc/my_app/keys_config.cs`
Підтримати Україну у боротьбі з країною-терористом.
Я наверное упустил про C#. Конфиг предполагается вкомпиливать в код? Ну, это может зачем-то и надо, только это уже не конфиг, а набор предопределенных значений.
Я иногда завожу класс с константами, в которых спрятаны или флажки для вкл/выкл экспериментальных фич, функционала, которые потом и в конфиг уехать могут, или просто констант по потребностям. Но это и не совсем конфиг.
Иногда ставлю настройки в отдельном .cs файле, в каких-нибудь враперах которые нужны во время разработки и не более того.
Здравствуйте, #John, Вы писали: J>Из плюсов: можно писать комментарии, удобная навигация по коду, при рефакторинге конфига меньше шансов получить ошибку с неправильным мапингом свойств в коде. Если надо этот конфиг расшарить с каким-то другим приложением, всегда можно так же как и раньше сериализовать объект с нужными полями в json напр. и передать другому приложению. J>Какие минусы по сравнению с тем же json/xml?
Самое простое — использовать один или несколько ini-файлов
Еше есть json для людей (для конфигов) — https://hjson.org/
В нем и комментарии есть, запятые висячие можно и т.п.
Есть парсеры для кучи языков, том числе C#
Есть еще YAML, но он сложноват, т.к. в нем куча нюансов, не все захотят разбираться.
config.cs стоит рассматривать только если он предназначен для правки программистами.
Для пользователей не подходит.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Так же есть старые добрые ini-файлы на любой вкус. Максимально просто формат, в него укладываются довольно много вещей и он так же всем понятен и легко читается как пользователями так и машиной.
Со всем согласен, кроме INI — слишком уж он плоский. Чуть шаг в сторону — становится гирей на ноге. Давайте дадим ему умереть
Ну, нюансов много может быть. Скажем пробелы в конце строки легко записать в форматах, где строки можно/нужно заключить в кавычки, в тоже время с ini файлами никогда не знаешь умеет ли конкретный софт это, поддерживает ли многострочные значения и т.п. Отсутствие внятного стандарта в свое время, тут, пожалуй навредило.
С js/json/python подробными объектами, на мой взгляд, работать просто не удобно, т.к. повышается уровень шума из-за очевидно ненужных кавычек вокруг имен ключей, иногда и значений. Так же, нет возможности задавать последовательные пары ключ=значения с гарантированным порядком, пока не позовешь парсер в ручную. Ну понятно, что можно в массив завернуть, добавив изрядное число новых скобок.
Я бы лично, предпочел XML, особенно, если он не автогенерен, а человеколюбиво оформлен, что в принципе возможно.
Но, опять же — если 5 значений — любой формат будет работать. Если это конфиг сложного продукта, на подобии фичастого веб-сервера, — то тут так сразу и не скажешь.
Безусловно, самый плохой выбор, на мой взгляд, json который без комментариев, потому как невозможно ни шаблон сформировать с описанием опций/значений, ни самому че-то временно подправить.
Поэтому: если xml кажется слишком сложным или неудобным, ini — все еще себе игрок.
Здравствуйте, Буравчик, Вы писали:
Б>Еше есть json для людей (для конфигов) — https://hjson.org/ Б>В нем и комментарии есть, запятые висячие можно и т.п. Б>Есть парсеры для кучи языков, том числе C#
А, забыл. Еще и кавычки не нужны! Можно их опускать как для ключей, так и для значений
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, Danchik, Вы писали:
D>>Это почему в JSON нельзя вставлять коментарии?
J>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json. J>Douglas Crockford написал пост, почему он решил не добавлять коменты в json, но все ссылки ведут на google++ который сдох.
Здравствуйте, #John, Вы писали:
J>в xml: файл с настройками получается плохо читаемым,
Почему?
J> нет возможности писать комментарии.
Ну здрасте. Кто украл комментарии из xml?
J>в json: нет возможности писать комментарии
В некоторых реализациях комменты есть.
J>Но, что если вместо конфигов сразу использовать C# код? Просто обычный C# класс J>Какие минусы по сравнению с тем же json/xml?
Десериализовать конфиг как? Запускать компилятор шарпа? Или парсить шарп самому?
Здравствуйте, #John, Вы писали:
J>Есть, но они сильно ограничены, потому что напр. нельзя закомментировать любой аттирибут в средине тега, J>нельзя написать комментарий возле аттрибута в теге.
Можно сконвертировать атрибут в тег.
J>Теперь если мы запускаем `./build.sh dev` (с ключем `dev` напр.), J>и скрипт сделает билд проекта `src/my_app` в дерикторию `./package/usr/bin/my_app` , J>скопирует `./etc/` в `./package/` J>а потом скопирует(с оверайдом) все файлы из дериктории `/env/dev/` J>и успешно перезапишет `./package/etc/my_app/keys_config.cs`
J>После установки пакета, приложение после запуска прочитает сначала конфиг `/etc/my_app/config.cs`, а потом динамический из `/etc/my_app/keys_config.cs`
Т.е., к примеру, чтобы поменять секрет к какому нибудь внешнему сервису нужно пересобирать и передеплоивать весь проект? Офигеть как удобно.
Здравствуйте, Jack128, Вы писали:
J>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.
Да, не JSON. Но JSON и не предназначен для конфигов, только для сериализации. А для конфигов используется похожий на JSON формат, но с комментариями. Потому что формат конфигов, не допускающий комментариев это полный и тотальный бред.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Jack128, Вы писали:
J>>Потому что. Json — это стандарт. И комментариев в нем нет. Json.NET умеет читать файлы с комментариями, но строго говоря такие файлы — это НЕ json.
НС>Да, не JSON. Но JSON и не предназначен для конфигов, только для сериализации. А для конфигов используется похожий на JSON формат, но с комментариями. Потому что формат конфигов, не допускающий комментариев это полный и тотальный бред.
Я даже видел, расширение .jsonc — JSON With Comments, который по умолчанию поддерживается VS Code.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Т.е., к примеру, чтобы поменять секрет к какому нибудь внешнему сервису нужно пересобирать и передеплоивать весь проект? Офигеть как удобно.
Если просто что бы подебажить, то напр. в локальном конфиге,можно просто закомментить нужное поле:
А так C# конфиги один в один такие же как xml или json . Если для разных окружений много разных значений, а не одно, которое можно закомментить как выше, то вполне логично что удобнее было бы создать скрипт(или таску как в msbuild), который будет заменять значения в базовом конфиге на специфичные окружению. А что бы динамически не генерить config.cs файл после запуска такого скрипта, то проще просто вынести части специфические для окружения в отдельный файл и просто заменять этот файл на нужный в зависимости от `env`.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Десериализовать конфиг как? Запускать компилятор шарпа? Или парсить шарп самому?
C# конфиг не надо десериализовать. Это просто config.cs файл, в котором несколько классов. После запуска проекта Progrma.proj этими классами можно пользоваться как обычными.
Підтримати Україну у боротьбі з країною-терористом.