AppSettings vs projektspezifische Einstellungen in Web.Config

Question

Okay, so hat dieses mich ein bisschen verwirrt. Ich habe folgendes:

string csvOfAttributes = CableSolve.Web.Properties.Settings.Default.GenerateBoothReportAttributes; 

und in meinem web.config:

<CableSolve.Web.Properties.Settings> 
    <setting name="GenerateBoothReportAttributes" serializeAs="String"> 
    <value>327, 329, 330, 369, 342</value> 
    </setting> 
</CableSolve.Web.Properties.Settings> 

Ich habe zwei Fragen dazu:

• Wenn ich meine Einstellung aus der Datei web.config auslassen Ich erhalte Kompilierungsfehler. Wie ist das möglich? Web.config kann vom Benutzer bearbeitet werden. Ich würde nur Laufzeitfehler erwarten. Wenn ich meine Anwendung kompiliere, deploy, dann bearbeitet der Benutzer den Namen dieser Einstellung - würde das den kompilierten Code nicht brechen?
• Ich könnte diese Einstellung möglicherweise im Abschnitt appConfig meiner Datei web.config speichern. Um auf die Werte zuzugreifen, würde ich ConfigurationManager durchlaufen - und ich würde nur ein Null-Objekt zur Laufzeit erhalten, wenn die Einstellung fehlt. Dies scheint weniger vorteilhaft zu sein, da ich meine Fehler bevorzuge, die während der Kompilierung auftreten, aber ich frage mich: Was sind die Unterschiede zwischen diesen beiden Optionen und wann sollte ich sie verwenden?

Answer 1

Ich denke, die Antwort vor allem in der Frage enthalten ist: der ganze Unterschied ist die grundlegenden Schlüssel-Wert-Paar Schemata Verse komplexere Schemata. Durch die Erweiterung bezieht sich der Unterschied auf schwach typisierte versus stark typisierte und Laufzeit versus Kompilierungszeit. Im Allgemeinen ist letzteres besser, in dem Sinne, dass .NET "besser" ist als JavaScript: Sie werden frühzeitig auf Fehler aufmerksam gemacht, anstatt dass sie in unvorhersehbarer und schwer nachvollziehbarer Weise in Ihre Anwendung eintauchen. Ausnahmen von dem starken Schema Präferenz könnten gehören:

• Ihre Anwendungsanforderungen entwickeln sich, so dass Sie in einem Schema
• Sie arbeiten mit einer Stamm-Level-Konfiguration, die verschiedenen Entwickler sperren wollen nicht oder Anwendungen verwenden werden
• Sie wollen „ungültig“ Konfigurationen zu ermöglichen und zu handhaben sie zur Laufzeit