Best practice für das Verwalten von Einstellungen in einer Software

Servus zusammen!

Es gibt sicher zig verschiedene Herangehensweisen für das Verwalten von Einstellungen in einer Software. Speichern in der Registry, in einer INI Datei, in einer Datenbank, usw...
Gibt es denn etwas das Ihr besonders bevorzugt, oder absolut verabscheut?

Hintergrund ist, dass ich aktuell das Modell "Serialisieren/Deserialisieren" nutze und mich frage ob es da nicht etwas besseres/schnelleres/einfachrereres gibt...

Kriz

Es gibt hier keine absolute Antwort, weil allein der Anwendungstyp (Desktop, Web, App...) gewisse Dinge von Haus aus ausschließt oder bevorzugt.
Und dann gibt es natürlich zig Anforderungen an eine Settings-Verwaltung, die dann auch noch die Art und Weise mit entscheidet.

Aber der erste Anlaufpunkt in .NET ist i.d.R.
[Tutorial] Konfigurationsmodell im .NET Framework

Das widerum ist aber nicht für alle .NET Szenarien geeignet bzw. veraltet.
So hat .NET Core ein neues Konfigurationsmodell (Konfiguration in ASP.NET Core), das durch ASP.NET Core entstanden ist, aber dank .NET Standard auch in .NET Framework Verwendung findet.
Es ist viel einfacher zu verwalten, deckt mehr Szenarien ab und lässt sich auch leichter in CI/DevOps Prozess einbinden.

Hallo Kriz,

für mich ist mittlerweile als "best practice" die Konfiguration von ASP.NET Core (siehe Abts Beitrag) hervorgegangen und zwar sowohl für .NET Core als auch .NET Full.

Dies v.a. wegen (ohne bestimme Reihenfolge):* es können verschiedene Konfigurationsquellen vereint werden, die sich in der Reihenfolge des Hinzufügens zum Konfigurations-Builder überschreiben -- dadurch können z.B. sensible Daten außerhalt der "Hauptkonfiguration" gespeichert werden und zur Laufzeit werden diese vom Framework zusammengeführt

• Konfigurationen für verschiedene Umgebungen (Debug / Production od. auch je nach Mandanten) können einfach umgesetzt werden -- ohne dass Konfigurations-Transformationen, etc. benötigt werden
• es können Konfigurationsquellen leicht selbst erweitert werden
• passt zusammen mit dem Options-Pattern sehr gut zu DI (dependency injection) -- lässt sich folglich auch leichter in Tests verwenden

mfG Gü