Wenn man Code oft oder ähnlich schreibt, dann ...
Kategorie C# .Net
ist es Zeit sich Gedanken zu machen, wie man es mit weniger Aufwand machen könnte.... So zumindest der Plan...
Wer schon ab und an ein Consolen-Program in C# geschrieben hat, der hat sicher ein paar Parameter in die sog. App-Config ausgelagert und diese beim Starten des Programmes ausgelesen.
class Program {
public staticint iMax = 0;
public staticstring sText = "JJR";
static void Main(string[] args) {
iMax = Convert.ToInt32(ConfigurationManager.AppSettings"iMax");
sText = ConfigurationManager.AppSettings"sText";
Console.WriteLine("iMax - " + iMax);
Console.WriteLine("sText - " + sText);
}
}
zumindest so oder ähnlich sieht es dann aus.
ist es Zeit sich Gedanken zu machen, wie man es mit weniger Aufwand machen könnte.... So zumindest der Plan...
Wer schon ab und an ein Consolen-Program in C# geschrieben hat, der hat sicher ein paar Parameter in die sog. App-Config ausgelagert und diese beim Starten des Programmes ausgelesen.
class Program {
public staticint iMax = 0;
public staticstring sText = "JJR";
static void Main(string[] args) {
iMax = Convert.ToInt32(ConfigurationManager.AppSettings"iMax");
sText = ConfigurationManager.AppSettings"sText";
Console.WriteLine("iMax - " + iMax);
Console.WriteLine("sText - " + sText);
}
}
zumindest so oder ähnlich sieht es dann aus.
nach einiger Zeit kommt man evtl. auf die
Idee die Konfigurationswerte in einer eigenen Methode auszulagern, welche
dann so aussehen könnte ->
staticvoid ReadConfigValuesNormal() {
string s = null;
s = ConfigurationManager.AppSettings"iMax";
iMax = (s != null) ? Convert.ToInt32(s) : iMax;
s = ConfigurationManager.AppSettings"sText";
sText = s ?? sText;
}
Hier wird halt erst noch geprüft, ob der Wert überhaupt in der App.Config drinnen steht, bevor er mit null überschrieben wird.
Dies hat den Vorteil, dass man in der / den Testumgebung/en einfach die Config weglässt und es funktioniert.
Im Produktiv-System einfach die Config dazu und gut.....
Und so kann es dann per Reflection aussehen ->
static void ReadConfigValuesReflection() {
FieldInfo[] fi = MethodInfo.GetCurrentMethod().ReflectedType.GetFields();
foreach (FieldInfo info in fi) {
string s = ConfigurationManager.AppSettings[info.Name];
if (s!=null) {
switch(info.FieldType.ToString()) {
case"System.String" :
info.SetValue(null,s);
break;
case"System.Int32" :
info.SetValue(null,Convert.ToInt32(s));
break;
}
}
}
}
Man muß die Felder in der Klasse einfach nur schön benennen, so dass es in der AppConfig auch Sinn macht und schon ist man durch.....
Das ganze kann man natürlich so erweitern, dass man in der AppConfig einfach den vollen Klassennamen angibt, dann wird es ein wenig flexibler ->
staticvoid ReadConfigValuesReflectionFullname() {
Type t = MethodInfo.GetCurrentMethod().ReflectedType;
FieldInfo[] fi = t.GetFields();
foreach (FieldInfo info in fi) {
string s = ConfigurationManager.AppSettings[t.FullName+"."+info.Name];
if (s!=null) {
switch(info.FieldType.ToString()) {
case"System.String" :
info.SetValue(null,s);
break;
case"System.Int32" :
info.SetValue(null,Convert.ToInt32(s));
break;
}
}
}
}
Gruß JJR
P.S.: Anbei die cs und config
staticvoid ReadConfigValuesNormal() {
string s = null;
s = ConfigurationManager.AppSettings"iMax";
iMax = (s != null) ? Convert.ToInt32(s) : iMax;
s = ConfigurationManager.AppSettings"sText";
sText = s ?? sText;
}
Hier wird halt erst noch geprüft, ob der Wert überhaupt in der App.Config drinnen steht, bevor er mit null überschrieben wird.
Dies hat den Vorteil, dass man in der / den Testumgebung/en einfach die Config weglässt und es funktioniert.
Im Produktiv-System einfach die Config dazu und gut.....
Und so kann es dann per Reflection aussehen ->
static void ReadConfigValuesReflection() {
FieldInfo[] fi = MethodInfo.GetCurrentMethod().ReflectedType.GetFields();
foreach (FieldInfo info in fi) {
string s = ConfigurationManager.AppSettings[info.Name];
if (s!=null) {
switch(info.FieldType.ToString()) {
case"System.String" :
info.SetValue(null,s);
break;
case"System.Int32" :
info.SetValue(null,Convert.ToInt32(s));
break;
}
}
}
}
Man muß die Felder in der Klasse einfach nur schön benennen, so dass es in der AppConfig auch Sinn macht und schon ist man durch.....
Das ganze kann man natürlich so erweitern, dass man in der AppConfig einfach den vollen Klassennamen angibt, dann wird es ein wenig flexibler ->
staticvoid ReadConfigValuesReflectionFullname() {
Type t = MethodInfo.GetCurrentMethod().ReflectedType;
FieldInfo[] fi = t.GetFields();
foreach (FieldInfo info in fi) {
string s = ConfigurationManager.AppSettings[t.FullName+"."+info.Name];
if (s!=null) {
switch(info.FieldType.ToString()) {
case"System.String" :
info.SetValue(null,s);
break;
case"System.Int32" :
info.SetValue(null,Convert.ToInt32(s));
break;
}
}
}
}
Gruß JJR
P.S.: Anbei die cs und config
| Permalink | 
Kommentare
ist schon eine schöne Sache die du da angefangen hast
[Configured("MaxValue")]
public static int iMax = 0;
[Configured("Text")]
public static string sText = "JJR";
Die Auslesemethode dann noch so erweitern dass nur noch alle Member mit dem Attribut gesetzt werden. Da sieht jeder was aus der AppConfig geladen wird und man kann dem Attribut sogar noch den Schlüssel des Eintrages in der AppConfig als Parameter mitgeben. Evt. auch hilfreich wenn man öfters mal mit Newbies zusammen arbeitet...
Nun habe ich da mal ein Beispiel gemacht für statische Felder und sehe gerade dass ich ja gar keine Dateien an den Kommentar ranmachen kann
Aber ich denke du verstehst meinen Vorschlag auch so
Viele Grüße,
Sebastian
P.S.: was man mit Reflection alles machen kann ist schon genial - und dann dazu noch Convert.ChangeType und man kann sich sogar das switch für den Type sparen
Erstellt von Sebastian Stricker um 10:18:51 PM am 11/09/2009 | - Website - |
die Convert.ChangeType kannte ich noch nicht, sollte doch ab und an mal Doku lesen
Das Beispiel kannste mir ja mal senden, dann werde ich es unter Deinem Namen posten...
Gruß JJR
P.S.: Schreibe niemals Code, den auch jemand anders schreiben kann
Erstellt von JakeJBlues um 11:06:38 PM am 11/09/2009 | - Website - |