Доброго всем!
Коллеги, поделитесь опытом к каким практикам для организации работы с настройками в приложениях/сервисах пришли и почему..

В частности интересны следующие моменты (и для затравки, привожу свой опыт)
в каком формате хранить?
В ini файлах — легко читать/править. большинство практических потребностей покрывает.
xml/json — сложнее править, больше шансов ошибиться при ручной правке. основное преимущество — возможность большей вложенности (иерархичность) настроек,
но на практике не особо ощущается т.к. в том же ini-файле вложенность вполне ок можно эмулировать за счет имен секций [system.limits]

более интересный вопрос — как в приложении организована работа (чтение/хот релоад)?
тут есть два подхода.
1. где-то заранее (в Startup/Init) читаем в спец класс-конфиг (в нём каждая проперть соотвествует какой-то конфиг-настройке).
но минус в том что, будет один класс который должен знать обо всех настройках всех подсистем.
суть минуса — наличие зависимости, необходимости правки общего места (класса-конфига) при возникновении необходимости в новой настройке в локальной подсистеме.
это и плюс с другой стороны — мы знаем все настройки, они перечислены, задокументированы кодом, легко ищутся их использования.

2. противоположный 1-му подходу. на старте создаем некий IConfigProvider и далее через него все подсистемы сами читают что им нужно.
+ каждая подсистема сама читает нужные настройки, при возникновении в ней новых — не надо править центральное место.
— нет единого места, где все перечислены (хотя можно доку написать и поддерживать).

что показывает практика, что лучше в долгую в среднем/большом проекте? единый класс-конфиг или каждый читает сам что нужно?


3. стандартный в .net подход с appsettings.
у меня не пошел. много церемоний, сложнее понимать.

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

MH>что показывает практика, что лучше в долгую в среднем/большом проекте?

...поэтому глупо спрашивать, какой ответ лучше — "8" или "16"? Под какую задачу вам нужен ответ??

MH>3. стандартный в .net подход с appsettings.
MH>у меня не пошел. много церемоний, сложнее понимать.

Как ни удивительно, (3) прекрасно живёт во многих проектах!

В моей практике, (3) используется практически всегда (позиция окошек, конекшены, последнее имя юзера, рабочая папка и т.п.).
Но если юзер держит какие-то важные (или объёмные) данные личного характера, делаю отдельный JSON, который всегда можно бэкапнуть.
Во всех остальных конфигах смысла как-то не было.

Здравствуйте, MadHuman, Вы писали:

MH>3. стандартный в .net подход с appsettings.

для корэ. позволяет выделять настройки в отдельные файлы. 1 класс <-> 1 json.
нюанс, если настройка должна изменяться (например, время последней успешной операции) это уже не настройка,
и для изменяемых "настроек" я бы сразу использовал БД т.к. в конечном итоге настроек становится много
и есть такие ситуации когда при зависании пк его перегружают и на выходе пустой xml файл с настройками.
Т.е. дотнет вроде записал в файл (видно по размеру), а кэш видимо не сброшен на диск.
С БД таких косяков не встречал.

yaml

MH>в каком формате хранить?
Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение. Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается Основной минус — если в файл "конфига" сможет писать хакер, то полный контроль над системой гарантирован. Но если проект не для масс-маркета и обслуживается персональным админом, этот вариант даёт 200% гибкости.

Здравствуйте, hi_octane, Вы писали:

MH>>в каком формате хранить?
_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода.

Нет такой альтернативы — конфиг или код. Если тебе не нужно менять настройки после компиляции — нет никакого смысла хранить их во внешних файлах. Если нужно — код в принципе не подходит.

Здравствуйте, MadHuman, Вы писали:

MH>Коллеги, поделитесь опытом к каким практикам для организации работы с настройками в приложениях/сервисах пришли и почему..

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration

MH>в каком формате хранить?

xml, json или yaml. Первый наиболее богат инструментами, второй более менее сейчас принят, третий — модно и молодежно, хотя более грабельный формат еще поискать.

MH>но на практике не особо ощущается т.к. в том же ini-файле вложенность вполне ок можно эмулировать за счет имен секций [system.limits]

Хочется тебе ini файлы в 2021 году — кто ж тебе запретит? Непонятно только что ты хочешь тут услышать.

MH>более интересный вопрос — как в приложении организована работа (чтение/хот релоад)?

См. выше.

MH>3. стандартный в .net подход с appsettings.
MH>у меня не пошел.

Поздравляю. Тот же вопрос — что ты хочешь тут услышать в ответ?

MH>много церемоний, сложнее понимать.

Пару строк кода это много церемоний? Ну ОК.

Здравствуйте, Ватакуси, Вы писали:

В>yaml

Аргументы есть? Или как обычно?

Здравствуйте, Ночной Смотрящий, Вы писали:

В>>yaml

НС>Аргументы есть? Или как обычно?

Более человеко-читаемый чем json (и тем более чем xml)
Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени
Есть иерархия и списки (в отличие от ini)
Можно писать комментарии, в отличие от json

Здравствуйте, bnk, Вы писали:

bnk>Более человеко-читаемый чем json (и тем более чем xml)

Обоснуй.

bnk>Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени

Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.

bnk>Можно писать комментарии, в отличие от json

В современном json комменты как правило можно таки писать.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, bnk, Вы писали:

bnk>>Более человеко-читаемый чем json (и тем более чем xml)

НС>Обоснуй.

Я имел в виду, меньше визуального мусора типа этих скобочек, запятых и т.д. Вот сравни


bnk>>Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени

НС>Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.

Это да, бесит. Но тут или шашечки или ехать. Питон же терпят.

bnk>>Можно писать комментарии, в отличие от json

НС>В современном json комменты как правило можно таки писать.

jsonc? Ну костыль конечно, но таки да.

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет такой альтернативы — конфиг или код. Если тебе не нужно менять настройки после компиляции — нет никакого смысла хранить их во внешних файлах. Если нужно — код в принципе не подходит.
Схренабы? Кто-то отменил compile on the fly?

Здравствуйте, Sinclair, Вы писали:

S>Схренабы? Кто-то отменил compile on the fly?

Нафига такая дурь в данном конкретном случае?

Здравствуйте, bnk, Вы писали:

bnk>Я имел в виду, меньше визуального мусора типа этих скобочек, запятых и т.д.

С чего ты взял что это мусор? Или это очередная песнь про синтаксический оверхед.


НС>>Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.
bnk>Это да, бесит.

Ну и нафига тогда?

bnk>>>Можно писать комментарии, в отличие от json
НС>>В современном json комменты как правило можно таки писать.
bnk>jsonc?

Нет, в обычном json. Парсер дотнетный по крайней мере без проблем потребляет конфиги с комментами.

Здравствуйте, hi_octane, Вы писали:

MH>>в каком формате хранить?
_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение. Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается Основной минус — если в файл "конфига" сможет писать хакер, то полный контроль над системой гарантирован. Но если проект не для масс-маркета и обслуживается персональным админом, этот вариант даёт 200% гибкости.

А можно пример, пожалуйста?

TG>А можно пример, пожалуйста?
Чего именно?

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sinclair, Вы писали:
S>>Схренабы? Кто-то отменил compile on the fly?
НС>Нафига такая дурь в данном конкретном случае?
Эмм. Вернёмся на шаг назад:

Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается

От себя добавлю: компайл-тайм (и едит-тайм) проверка валидности конфига; наличие инструментов по рефакторингу, автодополнению, и прочему.
Никаких проблем перекомпилировать конфиг после перечитывания нет, почему это "дурь" — решительно непонятно.

Здравствуйте, hi_octane, Вы писали:

_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода.
с моей тз минус — нельзя сделать хот релоад. хотя если поприседать может и можно..

Здравствуйте, MadHuman, Вы писали:

MH>Доброго всем!
MH>Коллеги, поделитесь опытом к каким практикам для организации работы с настройками в приложениях/сервисах пришли и почему..

MH>в каком формате хранить?

https://github.com/lightbend/config/blob/master/HOCON.md

Формат вменяемый, удобный, не заточен на пробелы. Библиотека для JVM, но есть порт на .NET

Здравствуйте, scf, Вы писали:

scf>https://github.com/lightbend/config/blob/master/HOCON.md
scf>Формат вменяемый, удобный



Это такая 1-апрельская шутка штоле??
Эта бредятина документирована на 14(!!!!) страницах. С виду — какой-то гибрид макросов и JSON. На деле — переусложнённая хрень, где в JSON просто вмешали какие-то местечковые задачки. Поверь старому анжанеру — это г****вно не взлетит. Даже hi_octane с его "кодом-как-конфиг" (дырявым донельзя) имеет бóльшие шансы.