ist es möglich für Variablennamen einen Ausdruck zu verwenden, so dass beim Refactoring Anpassungen sofort mit durchgeführt werden.
Zum Beispiel kann man das ja bei Klassen so machen ...
String className = typeof(TestClass).FullName;
Gibt es da auch eine Möglichkeit für Variablen? Hintergrund ist der, dass ich für verschiedene Instanzvariablen in einer Interfacemethode zur Serialisierung anmelden möchte. Gegenwärtig habe ich das so gelöst, dass man eine Set und Get-Methode überschreibt und hier den Namen der Variablen (als String) und den Wert (als Object) in ein Dictionary-Objekt packt.
Jetzt dachte ich, dass das einfacher gehen soll und ohne Variablennamen als String. Ich dachte an eine Methode IList<???Identifier??, Object> GetSerializableVariables nur welchen Identifier nehme ich hier.
Gibt es eine andere Möglichkeit, z.B. int, String, double ect. überladen und neuen Typ, z.B. SerializableInt, SerializableString zuweisen und mittels Reflektion werden dann diese Typen nach dem Instanzieren manipuliert?
Wie löst ihr das?
Danke schon mal für etwaige Antworten im Voraus?
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von mosspower am .
das mit den Attributen ist eine super Idee, vielen Dank. Jetzt muss ich nur noch mal gucken ob das mit privaten Instanzvariablen auch geht und dann mittels Reflection bei der Instanzierung die serialisierten Werte setzen.
[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property)]
class SerializableField : Attribute {
}
und im Code dann benutze ich die halt mit Attributes ... z.B. ...
[SerializableField]
private int blub = 0;
[SerializableField]
private String bla = String.Empty;
private Decimal nonSerializable = 0.0m;
Wird die Applikation runtergefahren, dann werden alle mit Attribut geflagten Fields und Properties mittels Reflektion serialisiert, beim Start werden dann die Werte gesetzt (wenn vorhanden), nach Instanzierung mittels Reflektion.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von mosspower am .
da hast Du recht, nur ist hier das Problem, dass ich einen String brauche um Operationen anzustellen, z.B. wenn Field name ist bla (wobei bla ein String ist, der soz. ein Verweis auf die Variable ist), dann mache das ... usw. ... das braucht man bei Klassen nicht (hier kann man ja Klassentypen vergleichen, bzw. abfragen). Die einzige Lösung, die mir eingefallen wäre (ohne die Attribute, die sind die beste Lösung) wäre gewesen, dass ich allen relevanten Variablen ein Postfix-Flag anhänge, z.B.
private int myTestVariable_ser;
.. dann hätti ich mit FieldInfos nur die mit dem Postfix serialisiert.
Gruß
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von mosspower am .
Warum verwendest du nicht die Attribute Serializable und NonSerialized und die Standardserialisierung von .Net?
Weil man das Attribute nicht bei Felder verwenden kann. Ich möchte nicht das ganze Objekt serialisieren, da es sehr viele und sehr große sind. Es geht hier um Teilservices innerhalb eines Services (also zig Threads), die z.B. Imports, Counter, Fehler, Warnings etc. hochzählen und diese möchte ich nicht verlieren, wenn ich den Service runterfahre. Denn dann würde ich ja z.B. wieder bei 0 anfangen wenn aber z.B. schon X Dateien importiert worden sind an diesem Tag.
Felder werden mitserialisiert. Beim XmlSerializer allerdings nur public Felder. Binäre und Soap-Formatierung verwenden beispielsweise nur Felder zur Serialisierung, egal ob public oder private.
Wenn du dir eine benutzerdefinierte Serialisierung einer Klasse wünschst, dann implementier das Interface IXmlSerializable oder ISerializable.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
ja, das hätte ich machen können, nur ist mir das im Moment zuviel Overhead, da es idR zwei bis drei Instanzvariablen sind (normaler Typ, also String oder int). Ich habe ja gegenwärtig schon eine lauffähige Lösung, ist auch so eine Art Anpassung an das Objekt, aber das erschien mir zu aufwändig, irgendwie wie mit Kanonen auf Spatzen schießen. Ich denke, dass die Lösung mit Attributes eine saubere (nicht die sauberste) und schnellste Lösung ist.