Tweet
Hallo,
ich stoße in letzter Zeit immer wieder auf ein Problem.
Wenn ich ein Problem habe, versuche ich immer eine möglichst gut wiederverwendbare Methode/Klasse zu schreiben, aber bei den Details stoße ich immer wieder auf Grenzen. Ein Beispiel :
Ich habe eine Klasse geschrieben, um tab-separierte Files in eine SharePoint-Liste zu importieren. Funktioniert auch einwandfrei. Ich verwende dazu ein von mir entwickeltes Data Access Object-Model, das ich mit Hilfe von Reflection schön parametrisiert befüllen kann. Nun muss ich in meinem speziellen Anwendungsfall aber zum Beispiel an Hand eines Feldes meines Data Transfer Objektes ein anderes befüllen (einen Filenamen aus einem Dictionary auslesen und eine URL daraus erzeugen). Das fest in mein allgemeingültiges Objekt einzuprogrammieren wäre ziemlich ungünstig, wenn ich es dann wieder woanders verwenden wöllte - würde auf Copy-Paste-Anpassen hinauslaufen.
Ich habe mir jetzt überlegt, dass ich an meine Methode eine weitere Klasse mit einem festen Interface übergeben könnte, das z.B. eine Methode implementiert wie (Pseudocode)
. Diese würde ich dann einfach an der entsprechenden Stelle aufrufen und die macht die Arbeit.
Ein weiteres Beispiel ist z.B. das Befüllen einer DataTable aus einem Excelfile oder das schreiben aus einer DataTable oder auch einem DataReader in ein Excelfile. Dort könnte es zum Beispiel sein, dass ich an Hand diverser Kriterien Felder einfärben will oder sogar Zusatzspalten berechnen (das könnte man auch vorher machen, z.B. aus dem DataReader eine DataTable entsprechend befüllen - da ich aber immer mit sehr großen Datenmengen arbeite, ist das a) RAM-lastig und b) auch nicht sonderlich performancefreundlich).
Bei beiden Problemen wäre jetzt die für mich naheliegendste Lösung über das Interface und die Klasse - finde ich aber irgendwie hässlich bzw. frage ich mich, ob es weniger umständlich geht. Vielleicht ist mir da irgendein Programmierkonzept entgangen oder ich denke in die falsche Richtung?
Ich wäre für jegliche Vorschläge dankbar.
Beste Grüße,
Compu
P.S.: Ich programmiere in C#, aber die VB-Welt ist ähnlich und wird nicht ausgeschlossen
/edit : Hm, vielleicht ist auch ein Eventkonzept denkbar? Also statt der Klasse mit dem Interface ein Event "newDtoAdded(ISPDto addedDto)". Gefällt mir jetzt erstmal besser, da es weniger aufwendig und der Zeitdruck immer groß ist... Ist für das obere Beispiel denkbar, muss man aber auch mit der Synchronisierung aufpassen... Und vielleicht nicht ganz so flexibel.. Hmmm...
/edit² : Wenn ich jetzt die Eventlösung nehmen würde - wie würde ich das mit dem Synchronisieren am elegantesten machen? Also ich will z.B. nicht, dass jetzt meine Änderungen committet werden, wenn der EventHandler noch nicht durchgelaufen ist. Oder wird das eh nicht passieren? Bin mit dem genauen Eventhandling noch nicht ganz so vertraut...
ich stoße in letzter Zeit immer wieder auf ein Problem.
Wenn ich ein Problem habe, versuche ich immer eine möglichst gut wiederverwendbare Methode/Klasse zu schreiben, aber bei den Details stoße ich immer wieder auf Grenzen. Ein Beispiel :
Ich habe eine Klasse geschrieben, um tab-separierte Files in eine SharePoint-Liste zu importieren. Funktioniert auch einwandfrei. Ich verwende dazu ein von mir entwickeltes Data Access Object-Model, das ich mit Hilfe von Reflection schön parametrisiert befüllen kann. Nun muss ich in meinem speziellen Anwendungsfall aber zum Beispiel an Hand eines Feldes meines Data Transfer Objektes ein anderes befüllen (einen Filenamen aus einem Dictionary auslesen und eine URL daraus erzeugen). Das fest in mein allgemeingültiges Objekt einzuprogrammieren wäre ziemlich ungünstig, wenn ich es dann wieder woanders verwenden wöllte - würde auf Copy-Paste-Anpassen hinauslaufen.
Ich habe mir jetzt überlegt, dass ich an meine Methode eine weitere Klasse mit einem festen Interface übergeben könnte, das z.B. eine Methode implementiert wie (Pseudocode)
Code:
void addAdditionalInfoToDto(ISPDto dto) {
// befüllt zusätzliche Felder
}
Ein weiteres Beispiel ist z.B. das Befüllen einer DataTable aus einem Excelfile oder das schreiben aus einer DataTable oder auch einem DataReader in ein Excelfile. Dort könnte es zum Beispiel sein, dass ich an Hand diverser Kriterien Felder einfärben will oder sogar Zusatzspalten berechnen (das könnte man auch vorher machen, z.B. aus dem DataReader eine DataTable entsprechend befüllen - da ich aber immer mit sehr großen Datenmengen arbeite, ist das a) RAM-lastig und b) auch nicht sonderlich performancefreundlich).
Bei beiden Problemen wäre jetzt die für mich naheliegendste Lösung über das Interface und die Klasse - finde ich aber irgendwie hässlich bzw. frage ich mich, ob es weniger umständlich geht. Vielleicht ist mir da irgendein Programmierkonzept entgangen oder ich denke in die falsche Richtung?
Ich wäre für jegliche Vorschläge dankbar.
Beste Grüße,
Compu
P.S.: Ich programmiere in C#, aber die VB-Welt ist ähnlich und wird nicht ausgeschlossen
/edit : Hm, vielleicht ist auch ein Eventkonzept denkbar? Also statt der Klasse mit dem Interface ein Event "newDtoAdded(ISPDto addedDto)". Gefällt mir jetzt erstmal besser, da es weniger aufwendig und der Zeitdruck immer groß ist... Ist für das obere Beispiel denkbar, muss man aber auch mit der Synchronisierung aufpassen... Und vielleicht nicht ganz so flexibel.. Hmmm...
/edit² : Wenn ich jetzt die Eventlösung nehmen würde - wie würde ich das mit dem Synchronisieren am elegantesten machen? Also ich will z.B. nicht, dass jetzt meine Änderungen committet werden, wenn der EventHandler noch nicht durchgelaufen ist. Oder wird das eh nicht passieren? Bin mit dem genauen Eventhandling noch nicht ganz so vertraut...