Lookup-Liste, Dictionary, best practice?

Question

Hallo Forum,
das Problem: mein Programm benötigt viele Parameter (meistens String), die für switch- usw. Entscheidungen oder einfach als Methodenparameter benötigt werden. Eine kleine Kostprobe:

switch (versionnr)

     {

      case ("2005SE32"):

       dirCopySource = "H:\\2005\\Mssql_2005_Englisch_32_bit\\Standard_Edition";

       dirCopySP = "H:\\2005\\Mssql_2005_Englisch_32_bit\\SP3";

       break;

      case ("2005EE32"):

       dirCopySource = "H:\\2005\\Mssql_2005_Englisch_32_bit\\Enterprise_Edition";

       dirCopySP = "H:\\2005\\Mssql_2005_Englisch_32_bit\\SP3";

       break;

      case ("2005SE64"):

       dirCopySource = "H:\\2005\\MSSQL_2005_English_64_Bit\\Standard_Edition";

       dirCopySP = "H:\\2005\\MSSQL_2005_English_64_Bit\\SP3_64bit";

       break;

      case ("2005EE64"):

       dirCopySource = "H:\\2005\\MSSQL_2005_English_64_Bit\\Enterprise_Edition";

       dirCopySP = "H:\\2005\\MSSQL_2005_English_64_Bit\\SP3_64bit";

       break;

      default:

       break;

Solche und ähnliche Angaben brauche ich im Programm am laufenden Band.
Was ist die beste Lösung für die Aufbewahrung solcher Infos: eine externe Textdatei (wie INI), ein Dictionary(jedes mal innerhalb des Programmstarts aufgebaut und event. ergänzt/korrigiert) oder "einfach" jede Menge vordefinierten Konstanten?
Danke für Eure Hilfe

Answer 1

Hi,

für mich sieht das erst einmal so aus, als ob ein Config-File ideal wäre. Hintergrund ist, dass der Admin der Applikation hier ja auch ggf. Dinge anpassen möchte. Somit sollte es auf jeden Fall ein externes, einfach zu verarbeitendes File sein. Und da kommt bei mir oft zuerst das Config-File in den Sinn.

Aber generell kann es auch durchaus sinnvoll sein, von einem Application Config File abstand zu nehmen, falls dies zu wenig optionen hat. Ich kenne die Anforderungen nicht, aber evtl. kann Deine Applikation ganz dynamisch alles machen und wenn eine MS SQL Server 2011 kommt, dann könnte evtl. jemand 2011EE32, 2011EE64, ... anlegen wollen....

Daher könnte man hier z.B. auch alles ganz dynamisch machen und die Applikation liest einen XML Node "SqlServerVersion" mit Attribut "Version" = deinem Versionsstring (z.b. 2005SE64) und liest dort die Childnodes "DirCopySource", "DirCopySP", u.s.w.

Du hast hier unbegrenzte Möglichkeiten....

Wobei ich jetzt davon ausgegangen bin, dass gewisse Dinge nur einmalig gebraucht werden. Wenn Du eine Applikation hast, die ständig so Pfade kennen muss, dann ist natürlich intern ein Dictionary sinnvoll, um schnell die benötigten Werte abrufen zu können. Aber wenn Du nur einmal eine Konfiguration lesen musst, dann macht das Dictionary keinen Sinn.

Soviel einfach einmal von meiner Seite wobei hier viel raten dabei war, da von den eigentlichen Anforderungen nicht viel bekanntgegeben wurde.

Mit den besten Grüßen,

Konrad

Answer 2

Hallo P.,

      > Was ist die beste Lösung für die Aufbewahrung solcher Infos

sollen denn die Infos von Administartor geändert werden können?
(Mit INI sowieso nicht mehr arbeiten, sondern wenn, dann mit XML-basierten config-Dateien, die aber .NET ggf. schon automatisch für Dich handlet). Aber man müsste ebene erstmal wissen, ob der Admin das ändern können soll, bzw. ggf. auch normale Benutzer.

---

ciao Frank

Answer 3

Hallo Frank, Hallo Konrad,

danke für Eure Antworten.
1. eine XML-Datei könnte tatsächlich die Lösung sein. Soll definitv von Admins editierbar sein.
2. sensible Daten (Passwörter!) werde ich nur "onfly" im Formular eingeben lassen, danach werden die niergendwo gespeichert
3. kann ich auch manche ComboBoxes mit dem Inhalt der XML-Datei versorgen? Hmm, sicherlich kann man das, muss ich nur gucken, wie ich das hinkriege..
4. ich gehe davon aus, wenn jemand die XML-Datei falsch speichert (ich meine das Format/Tags), dass der XML-Parser das merkt und dann kann ich eine MessageBox einblenden und das Programm abbrechen.
5. Manche Infos (so wie Konrad schreibt) muss ich mehrmals auslesen-dann doch lieber ein Dictionary?

Grüße

Answer 4

Hallo,

nur als kleine weitere Infos:

- Der XML Parser meckert schon, wenn das XML nicht valide ist, also gegen ein paar grundlegende Regeln verstößt. Also z.B. ein falsches Ende-Tag. Aber hier kannst Du auch sehr genau Vorgeben, wie das XML aufgebaut sein muss über ein Schema (xsd Datei). Die wird dann auch im XML referenziert und wird dann ebenfalls geprüft. Desweiteren hilft so ein Schema beim Erstellen der XML Datei (Visual Studio ist z.B. auch in den Express Versionen sehr gut und hilft, wenn die xsd Datei eingebunden wird.

- Ein Dictionary wird nur dann gebraucht, wenn du mehrere Zugriffe hast, die auch schnell erfolgen müssen. Wenn Du alles in einer XML Datei hast und diese nicht besonders groß wird, dann kannst Du diese aber auch einfach laden und dann per XPath darauf zugreifen. (Ein Dictionary wäre nur dann notwendig, wenn Du sehr viele Einträge hast und sehr performante Zugriffe brauchst!)

- Das mit den Passwörtern machst Du schon korrekt. Wobei hier mein Hinweis noch wäre, hier immer zu versuchen, auf Passwörter ganz zu verzichten. WIndows integrated Authentication wäre dann hier das entsprechende Stichwort. Bei Passwörtern muss man sonst sehr gut aufpassen. Wenn Du ein Eingabefeld hast, dann kann das z.B. von dritten Applikationen ausgelesen werden (Es reicht eine einfache Message an die Applikation mittels SendMessage mit dem Befehl "Kopier mir mal deinen Inhalt".) Und Spezialisten gehen hier sogar so weit, dass die sogar verhindern, dass sowas z.B. in einer Auslagerdatei landen könnte und so ...)

Das nur als kleine Anregungen.

Mit den besten Grüßen,

Konrad 

Answer 5

Hallo P.,

1. ok, wenn es von Admins editierbar sein soll, würde ich dennoch nicht eine rohe XML-Datei anbieten, sondern eine Oberfläche für solche Änderungen. Das XML speicherst Du dann ganz normal über .NET Anwendungseinstellungen. Evtl. auch über Methoden wie: http://dzaebel.net/XmlAsCsharpClass.htm o.ä..

2. Sensible Daten wie Passwörter können zum Beispiel über die ProtectedConfiguration-Klasse sauber in verschlüsselten CDATA-Feldern persistiert werden. Oder zum Beispiel über DPAPI gehen. Intern hält man ansonsten Passwörter möglichst in einem SecureString, aber wenn, dann natürlich möglichst ohne Passwörter in der App arbeiten. Die Data Protection API (DPAPI), ermöglicht das Verschlüsseln von Daten zum Beispiel mithilfe von Informationen vom aktuellen Benutzerkonto oder Computer.  Bei Verwendung der DPAPI umgeht man die schwierige Aufgabe, einen kryptografischen Schlüssel explizit zu generieren und speichern zu müssen. 

3. Du kannst ComboBoxen direkt an die Daten der Konfiguration binden - ja, sehr einfach und empfehlenswert, dann etwa den DataSource (ggf. noch DisplayMember und ValueMember setzen).

4.  Mit falscher Speicherung hättest Du nichts zu tun, wenn Du die Daten über die Applikation etwa in einem PropertyGrid präsentiert änderbar machst. Aber natürlich hätte würde normal auch .NET das beim Laden erkennen.

5. Ein Dictionary braucht Du hier eigentlich nicht (auch nicht bei vielen), wenn Du die Klassen-Instanz mitsamt der Unterklassen hast, ist die Performance auch bei vielen Instanzen sehr hoch (ebenfalls etwa ein O(1)-Vorgang). Ein Dictionary kann in anderen Szenarien sinnvoll sein. Die Konfigurations-Instanz wird ja bei App-Beginn komplett erstellt, das braucht man also nicht mehr zu cachen.

---

ciao Frank

Answer 6

Hallo Frank, hallo Konrad,

vielen Dank für Eure Vorschläge. Bin noch dabei die Links von Frank "abzuarbeiten" (und vor allem verstehen :-) ).
LG

Answer 7

Hallo P.,

• > Bin noch dabei die Links von Frank "abzuarbeiten" (und vor allem verstehen :-) ).

wenn natürlich "blockierende" Probleme auftreten sollten, kannst Du auch gern noch einmal nachfragen.

---

ciao Frank