2009-06-29 1 views
1

Ich möchte eine Benutzerkonfiguration über eine Benutzerkonfigurationsdatei initialisieren. Der Pfad für die Datei kann aus der Registrierung gelesen werden. Die Datei befindet sich in einem Ordner mit dem Benutzernamen.Klassendesign/beste Methode zum Initialisieren einer Benutzerkonfigurationsdatei

Also muss ich die folgenden Funktionen:

  • eine Zeichenfolge aus der Registry
  • Aufbau der Pfad in die Konfigurationsdatei Lesen
  • die Datei in ein Konfigurationsobjekt Lese

Jetzt gibt sind mehrere Ansätze, um damit umzugehen:

Zuerst brauche ich

  • ein „Helfer“ -Klasse für den Dateipfad bekommen (wir es Geteilt nennen)
  • ein „Container“ -Klasse für die Konfigurationsinformationen (lassen Sie uns Konfiguration nennen)

So, Shared hat eine Funktion/Eigenschaft wie UserConfigurationFile, die den Pfad zur Konfigurationsdatei zurückgibt.

, um den Pfad der Datei zu erhalten Ich habe eine Funktion InitializeUserConfigurationFile(), die im Konstruktor Shared genannt wird:

class Shared { 
    public Shared() 
    { 
     InitializeUserConfigurationFile(); 
    } 

    void InitializeUserConfigurationFile() 
    { 
     // 
     // Reads username 
     // 

     // 
     // Reads path from Registry 
     // 

     // 
     // etc. 
     // 

    } 


    // 
    // etc. 
    // 
} 

Irgendwelche bessere Vorschläge?

Wenn ich möchte, dass meine Container wir verschiedene Optionen initialisieren:

  • Ist es am besten, die Benutzerkonfiguration innerhalb des Konstruktors zu initialisieren?

Sth. wie:

class Container 
{ 
    Shared shared = new Shared(); 

    public Container() 
    { 
     InitializeUserConfiguration(); 
    } 

    void InitializeUserConfiguration() 
    { 
     LoadConfiguration(shared.UserConfigurationFile); 
    } 

    void LoadConfiguration(string filename) 
    { 
     // 
     // Initializes all parameters frome filename 
     // 
    } 
} 
  • Oder durch zwei Schritte (durch eine eigene Methode LoadConfiguration())?

Sth. wie:

Shared shared = new Shared(); 
Container container = new Container(); 

container.LoadConfiguration(shared.UserConfigurationFile); 
  • oder im Konstruktor von Containern durch einen Dateinamen liefert?

Sth. wie:

Shared shared = new Shared(); 
Container container = new Container(shared.UserConfigurationFile); 

oder alles in Container ..?

Es gibt so viele Möglichkeiten ...

Ich hoffe, dass jemand ein Best-approch weiß ...

Grüße,

Inno

Antwort

3

Es ist besser, Standardkonfiguration Klassen in .net existieren zu verwenden. Wie ApplicationSettingsBase und Configuration.

Hier können Sie gute Artikel-Serie finden:

  1. Unraveling the Mysteries of .NET 2.0 Configuration
  2. Unraveling the Mysteries of .NET 2.0 Configuration
  3. Cracking the Mysteries of .NET 2.0 Configuration
+0

Und was zu tun, wenn Sie eine bestimmte Anwendung haben, die diese Art der Konfiguration (mit eigenen Dateien) seit Jahren verwendet? – Inno

+0

Wenn es funktioniert, nicht berühren. Aber Sie fragen nach dem besten Ansatz, ich schlage vor, Sie am besten Ansatz :) Im Allgemeinen, mit Standard-Klassen, müssen Sie weniger schreiben, verbringen weniger Zeit und machen weniger Fehler. Vielleicht müssen Sie also über das Konfigurations-Refactoring in einer der zukünftigen Versionen nachdenken. – arbiter

+0

"Aber Sie fragen nach dem besten Ansatz, ich schlage vor, Sie am besten Ansatz :)" Ja, Sie haben;) Aber wenn Ihre Anwendung nicht Best-Ansatz, sondern "einige Ansatz" unterstützt, brauchen Sie den besten Ansatz, um diese "einige Ansatz "% -) – Inno

1

Für beste Praktiken, do nicht die Registrierung verwenden, und dies nicht tun das Rad neu erfinden.

Da Sie es nicht erwähnt haben, haben Sie sich den System.Configuration-Namespace angesehen?

Das .NET Framework enthält ein perfektes Konfigurationssystem, das gut getestet wurde. Es ist auch die Domäne von Sys Admins, die auch über Konfigurationsdateien und die begleitenden Tools Bescheid wissen.

Es ist also unklar, warum Sie das Rad neu erfinden und es vielleicht ein bisschen weniger rund machen.

Es gibt praktische Gründe, die Registry zu meiden (Distribution, Backup), aber auch, wie der Arbiter darauf hinweist, dass es nicht auf andere (zukünftige) Plattformen verschoben wird. Haben Sie bemerkt, dass diese Namespaces nicht mit System beginnen?

+0

Warum nicht die Registrierung verwenden? Mein Kollege möchte, dass ich weitere Informationen in der Registrierung in zukünftigen Versionen speichern werde ... – Inno

+0

Ohne Registrierung kann Ihre Anwendung xcopy deployable sein, und in Zukunft wird es einfacher sein, Mono-Port zu machen. – arbiter

+0

@arbiter: thx, da dies keine Kriterien für unsere Anwendung sind Ich denke, es ist in Ordnung, die Registrierung zu verwenden ... Ich habe an mehreren Stellen gelesen, die Registrierung nicht zu verwenden, und es wird empfohlen, im Allgemeinen Konfigurationsdateien zu verwenden, aber ich didn Finde keine richtige Erklärung, warum die Registry nicht benutzt werden sollte. (Ich habe nicht das Gefühl, dass es eine gute Idee ist, Konfigurationsinformationen aus vorhandenen Konfigurationsdateien in die Registrierung zu verschieben, aber ich habe keine Argumente dagegen. Ich möchte die Konfiguration an einem einzigen Ort behalten.) – Inno

Verwandte Themen