Konfigurationseinstellungen in (web.config|app.config) versus ein statisches Klassenobjekt

Question

Ich habe mir gerade den Quellcode von BlogEngine.Net angesehen und war fasziniert davon, wie die Anwendungseinstellungen gespeichert werden.

Anstatt web.config oder app.config zu verwenden, an die ich gewöhnt bin, verwendet die Quelle ein statisches Klassenobjekt, das mit einem Singleton-Muster implementiert wird, um die Anwendungseinstellungen zu erreichen. Die Informationen werden immer noch in einer Einstellungsdatei gespeichert, aber alle Aufrufe zum Abrufen von Informationen erfolgen über das Klassenobjekt, das alle Informationen in Eigenschaftswerte vorgeladen hat.

Gibt es Vorteile der verschiedenen Ansätze?

Answer 1

Wenn Sie einen Admin-Bereich haben, in dem Sie die Konfigurationseinstellungen ändern können, führt das Schreiben in die web.config dazu, dass die Anwendung neu gestartet wird und alle Benutzer ihre Sitzungsdaten verlieren. Die Verwendung einer separaten Konfigurationsdatei wird dies verhindern.

Answer 2

Ein schwerwiegender Nachteil dieses Modells besteht darin, dass Änderungen, die außerhalb der Anwendung vorgenommen werden, nicht erfasst werden können. Da die Konfigurationseinstellungen beim Start geladen und im Speicher gehalten werden, müssen alle Änderungen entweder über die Verwaltungsseiten vorgenommen werden oder während die Anwendung offline ist.

Answer 3

Es gibt Vor- und Nachteile von Eigenschaften, die als Accessors für Konfigurationseinstellungen dienen.

Einerseits bietet eine solche Klasse mit Eigenschaften dem Entwicklungsteam einen besser organisierten und wiederverwendbaren Code.

Andererseits: Müssen Sie jedes Mal, wenn Sie eine neue Konfigurationseinstellung hinzufügen, die Klasse aktualisieren und die Anwendung neu erstellen?

Answer 4

Nach meinem Verständnis werden die web.config-Dateien beim Start der Anwendung in den Cache geladen. Ich habe dies nicht in eine sehr lange Zeit nachgeschlagen, so dass ich falsch sein könnte. Wenn es wahr ist, dann sehe ich nicht wirklich, warum ein Singleton, statische Klasse Muster von Vorteil wäre. Wenn der ASP.Net State Service oder ein SQL State Server anstelle der standardmäßigen prozessinternen Sitzungsverwaltung verwendet wird, hat ein Neustart der Webanwendung (über IIS oder durch Ändern der Konfiguration) keine Auswirkungen auf die Sitzungen. Alles in allem bin ich mir nicht ganz sicher, warum blogengine.net diesen Weg gehen sollte.