2016-10-21 2 views
2

In meiner Web-Anwendung, las ich einige Einstellungen von einer externen Konfigurationsdatei während Application_Start, sie dann über die vielen Methoden der Anwendung aufzurufen:Müssen diese statischen Anwendungseigenschaften gesperrt werden?

namespace Common 
{ 
    public static class CommonConfigSettings 
    { 
     public static string DataSource { get; set; } 
     public static string DatabaseName { get; set; } 
     public static string DatabaseUserName { get; set; } 
     public static string DatabasePassword { get; set; } 
    } 
} 

Während Application_Start diese aus einer XML-Datei in die statische Variable gelesen werden:

DataSource = els.FirstOrDefault(item => item.Attribute("key").Value == "DataSource").Attribute("value").Value; 
DatabaseName = els.FirstOrDefault(item => item.Attribute("key").Value == "DatabaseName").Attribute("value").Value; 
DatabaseUserName = els.FirstOrDefault(item => item.Attribute("key").Value == "DatabaseUserName").Attribute("value").Value; 
DatabasePassword = els.FirstOrDefault(item => item.Attribute("key").Value == "DatabasePassword").Attribute("value").Value; 

Bei der Anwendung sie werden wie folgt verwendet:

myConn.ConnectionString = string.Format("Persist Security Info=False; User ID={0}; Password={1}; Initial Catalog={2}; Data Source={3}; Connection Timeout=60", 
    CommonConfigSettings.DatabaseUserName, 
    CommonConfigSettings.DatabasePassword, 
    CommonConfigSettings.DatabaseName, 
    CommonConfigSettings.DataSource); 

Zu keinem Zeitpunkt werden die statischen Werte in die folgenden Application_Start geschrieben - sie werden nur wieder ausgelesen (obwohl vielleicht von 2 + Personen gleichzeitig). Es gibt auch keine statischen Methoden, nur Eigenschaften. Ich lese über Verriegelung und Gewindesicherheit here und here, habe mich aber nur verwirrt. Soll ich diese Werte sperren und wenn ja, an welchem ​​Punkt bitte?

Antwort

2

Wenn Sie absolut sicher sind, dass diese Eigenschaften nur einmal geschrieben werden (und vor allen Lesevorgängen), müssen Sie nicht sperren.

EDIT: Die Frage ist: Wird es immer so sein? Wenn Sie diese Datenbankzugriffsinformationen zur Laufzeit ersetzen müssten, würden Sie auf das Problem der nicht-atomaren Operationen stoßen (z. B. Lesen eines neuen Datenbank-Benutzernamens und eines alten Passworts, wenn der Schreib-Thread auf der rechten Seite unterbrochen wäre). falsche Zeit). Vielleicht wäre es gut, eine Methode bereitzustellen, um alle benötigten Daten in einer einzigen Struktur zurückzugeben. Dieses Verfahren kann mit einem Gewinde Verriegelungsmechanismus in der Zukunft zur Verfügung gestellt werden, wenn die Notwendigkeit entstehen würde ...

public struct DatabaseAccessData 
{ 
    public string DataSource { get; set; } 
    public string DatabaseName { get; set; } 
    public string DatabaseUserName { get; set; } 
    public string DatabasePassword { get; set; } 
} 

public static class CommonConfigSettings 
{   
    private static string DataSource { get; set; } 
    private static string DatabaseName { get; set; } 
    private static string DatabaseUserName { get; set; } 
    private static string DatabasePassword { get; set; } 

    public static void SetDatabaseAccessData(DatabaseAccessData data) 
    { 
     DataSource = data.DataSource; 
     DatabaseName = data.DatabaseName; 
     DatabaseUserName = data.DatabaseUserName; 
     DatabasePassword = data.DatabasePassword; 
    } 

    public static DatabaseAccessData GetDatabaseAccessData() 
    { 
     return new DatabaseAccessData 
     { 
      DataSource = DataSource, 
      DatabaseName = DatabaseName, 
      DatabaseUserName = DatabaseUserName, 
      DatabasePassword = DatabasePassword 
     }; 
    } 

Lassen Sie uns sagen, dass ich keinen Fan von „statisch“ bin in diesem Fall. Wenn einige Ihrer Klassen von den allgemeinen Konfigurationseinstellungen abhängig sind, sollten Sie ihnen eine Instanz von CommonConfigSettings über den Konstruktorparameter oder die Eigenschaft übergeben (siehe "Dependency-Injektion"). Ich bevorzuge das erste, da es strenger/strenger ist; Sie können nicht vergessen, eine wichtige Abhängigkeit dann zu übergeben.

+0

Danke - das ist gut zu wissen. Ist das Sperren dann erforderlich, wenn die Kombination von gleichzeitigem Schreiben und Lesen eingeführt wird (was ist sinnvoll)? – EvilDr

+2

Gerade für diesen Fall bearbeitet. ;-) Ja, wenn simultanes Schreiben und Lesen der Fall wäre, müssten Sie einen Sperrmechanismus haben. – Udontknow

+0

* "alle benötigten Daten in einer einzigen Struktur zurückgeben" *. Entschuldigung, kannst du bitte erklären, was das bedeutet (wie anders ist es, was ich gerade mache)? – EvilDr

Verwandte Themen