Ich war kürzlich am Patchen eines Web-App-Projekts beteiligt und bemerkte die vorherige vom Entwickler verwendete Datenbanktabelle für Konfigurationseinstellungen anstelle von web.config (app.settings).Konfigurationseinstellungen für Web-App - Best Practices
Welche sollte ich verwenden? web.config oder Datenbanktabelle? Welches das Beste ist?
Dinge sollten die web.config in den folgenden Situationen gehen in:
Sie sind Dinge, die verfügbar sein müssen, um die Datenbank verfügbar
Sie machen‘(db Connection String!) Dinge, die, wenn sie sich ändern sollten, möchten, dass der Anwendungspool aktualisiert wird, oder die sich wahnsinnig wahrscheinlich ändern.
Sie Dinge sind, die verfügbar sein müssen, wenn die Datenbank aus irgendeinem Grund nicht verfügbar ist (wie zum Beispiel eine Liste von E-Mail-Adressen und einem SMTP-Server Fehlermeldungen an, oder Standorte zu senden, wo Log-Dateien gehören)
Dinge sollten die Datenbank in den folgenden Situationen gehen in:
Sowohl Ihre DB und Ihre Web-Schicht, die Konfiguration verwenden.
Sie müssen die Konfiguration im laufenden Betrieb ändern können, ohne eine Aktualisierung des Anwendungspools erzwingen zu müssen.
Das heißt - wenn Sie Sie wahrscheinlich in der Web-Schicht in irgendeiner Weise cachen wollen gehst, um Ihre config in der Datenbank setzen, so dass Sie die db nicht unnötig treffen sind. Ich empfehle die Cache-Klasse dafür.
Zusätzlich zu all dem oben genannten müssen Sie auch die Richtlinien Ihres Unternehmens für die Arbeit mit Ihren Servern berücksichtigen. Wenn es sehr, sehr schwer für Sie ist, mit der db zu arbeiten, könnte es sinnvoller sein, Dinge in die web.config zu legen und umgekehrt.
Was meintest du mit folgendem? * Sowohl Ihre DB als auch Ihre Webebene verwenden diese Konfiguration. * – Sam
Es macht Sinn, warum die vorl. Dev benutzte die DB zum Einstellen, geh mit. Sie müssen eine web.config haben, ich denke, dass ein ASP.NET ohne es nicht funktionieren kann. Die Projektkonfigurationseinstellung sollte in web.config (Deklarationen von benutzerdefinierten Steuerelementen, zusätzlichen Assemblys usw.) übernommen werden, aber Benutzereinstellungen oder andere spezifische Informationen zur Geschäftslogik sind möglicherweise in der Datenbank besser aufgehoben.
Nein Ich verstehe web.config ist erforderlich, aber es ist die App-Einstellungen Abschnitt, über den ich nicht sicher war. Grundsätzlich war ich unter dem Eindruck, dass App-Einstellungen sinnvoll sind - schnell und einfach Änderungen vorzunehmen, wenn sich die db config ändert etwas unordentlicher ist. Du hast recht, wenn du die vorherige Dev-Arbeit nicht änderst, wenn sie nicht kaputt ist, ändere sie nicht. – Rob
Ein Streitpunkt zwischen Entwicklern und DBAs in meiner Firma.
Meiner Meinung nach sollten Sie Konfigurationsdateien immer für Anwendungsebene, schreibgeschützte Einstellungen verwenden. Wenn die Einstellungen benutzerspezifisch oder zur Laufzeit editierbar sind, können Sie den Ansatz möglicherweise nicht erneut prüfen.
Ich habe Situationen gesehen, in denen Einstellungen in der Datenbank gespeichert sind, die intern in gespeicherten Prozeduren verwendet werden. Ich kann eine Begründung dafür sehen, aber es ist nicht kritisch, da der Wert über einen Parameter an die Prozeduren übergeben werden kann.
Guter Punkt betrifft gespeicherte Procs. Ich denke, die Konfiguration in der Datenbank erleichtert den Datenbankzugriff erheblich. Dieses Prev Dev verwendete jedoch jede Einstellung für Benutzer und App. – Rob
Eine Überlegung kann sein, dass der Entwickler nach der Implementierung der Webanwendung nicht mehr auf die Dateien web.config in der Produktionsumgebung zugreifen konnte.
Wenn er gelegentlich Einstellungen anzeigen muss, um jede Art von Unterstützung bereitzustellen, können Einstellungen in einer Datenbank, in der er nur Lesezugriff auf eine Konfigurationstabelle erhält, sehr sinnvoll sein.
Ein Vorteil für die Verwendung einer Datenbank für die Einstellungen ist, dass Dinge im laufenden Betrieb geändert werden können, ohne die Produktions-Website zu stören.
Änderungen an der Datei "web.config" führen dazu, dass die Worker-Prozesse in IIS wiederverwendet und die App neu gestartet wird. Wenn Sie InProcess-Sitzungen verwenden, gehen diese verloren. Dies könnte die Benutzer Ihrer Website möglicherweise stören.
Wir verwenden eine Kombination aus web.config-Einstellungen und Einstellungen auf Datenbankebene.
Für jede Einstellung stellen wir die folgende Frage: "Ist diese Einstellung spezifisch für den Computer, auf dem die Anwendung ausgeführt wird?" Wenn ja, dann geht es in die web.config. Wenn nicht, dann stellen wir eine zusätzliche Frage: "Wenn diese Einstellung geändert wird, sollte die App zum Neustart gezwungen werden?" Wenn ja, web.config. In den meisten Fällen ist ein Neustart für unsere Service Level Agreements nicht akzeptabel.
Die meisten unserer Anwendungen sind mandantenfähig und/oder werden in einer Webfarm ausgeführt. Einfache Dinge wie ein lokaler Dateisystempfad, Logging-Level oder Verbindungszeichenfolgen für die Datenbank werden in der Datei web.config angezeigt. Der Grund dafür ist, dass diese sich mit Ressourcen befassen, die für diese Maschine spezifisch sind.
So ziemlich alles andere wird die Programmausführung beeinflussen und sowohl für die App- als auch für die Datenebene zugänglich sein. Sie werden auch von anderen Anwendungen benötigt (vorausgesetzt, dass mehrere Anwendungen dieselbe Datenbank verwenden).
Ein Anwendungsfall, der für eine Datenbank spricht, sind Anwendungen mit Lastenausgleich, wie Webfarmen. Möglicherweise gibt es einige Einstellungen, die für eine einzelne Maschine relevant sind, die sich von den anderen Maschinen in der Farm unterscheidet und die in die web.config gehen müssen, aber es wird wahrscheinlich eine ganze Reihe von Einstellungen geben, die in der Farm identisch sein sollen . Die Farm sollte von außen wie eine einzige Anwendung aussehen und kann davon profitieren, wenn sie wie eine einzelne Maschine konfiguriert werden kann. Das bedeutet eine Art gemeinsames Repository wie eine Datenbank.
Schätzen Sie das zusätzliche Tag, danke Andy :) – Rob