Softwaredesign mit generierten Klassen
Hallo,
ich nutze einen OR-Mapper und lasse mir Entityklassen generieren. Diese würde ich gern "minimalinvasiv" erweitern. Es kommt nach der ERweiterung des Datenmodells immer wieder vor, dass ich Klassen neu generieren muss. Kurzum: ich möchte die generierten Klassen nicht verändern.
Derzeit leite ich Subklassen von diesen generierten Klassen ab und erweitere Sie um zusätzliche Funktionalitäten/Properties.
Irgendwie ist das aber total nervig, da ich Objekte der generierten Klassen in die erweiterten Klassen konvertieren muss und wenn ich dann ein Objekte via OR-Mapper zurückschreibe das Ganze wieder umwandle.
Geht alles gar nicht und die Lösung sollte nur so lange eingesetzt werden bis mir etwas besseres einfällt. Und hier sind wir bei der Idee:
Wäre es guter stil die Objekte der generierten Klasse in einer Wrapper Klasse aufzunehmen?
Das Objekt wäre dann eine Eigenschaft (vom Typ der generierten Klasse) in der Wrapperklasse und die zusätzliche Funktionalität würde einfach die Wrapperklasse zur Verfügung stellen.
Über Euer Feedback würde ich mich sehr freuen.
Beste Grüße antoschka.
Hallo antoschka,
wenn die Klassen eh generiert werden, würde ich erwägen, ob du nicht ein Tool zum Einweben deiner Ergänzungen schreibst. Dieses Tool würde den Output des ersten Generators und außerdem eine Beschreibungsdatei mit den Ergänzungen einlesen und daraus die fertige Klasse inkl. der Ergänzungen erzeugen.
herbivore
Hallo antoschka,
Vielleicht ginge es, dass du die generierten Klassen mit partial erweiterst, dann kannst du deinen Code in einer anderen Datei belassen. (Dafür ist partial ja gedacht.)
Geht natürlich nur, wenn man den OutPut des Generaturs anpassen kann.
Gruß
Juy Juka
Also einen eigenen Generator zu schreiben scheidet als Option glaube ich aus. Die Entwicklung soll mittelfristig von anderen übernommen werden und schreckt zuviel drum herum ab. Würde da lieber auf die üblichen Basistechnologie zurück greifen.
Das mit dem Partial klingt schon besser. Wie würdet Ihr das im Vergleich zu einem von mir beschriebenen Wrapper bewerten (auch im Hinblick auf Performance, schließlich müssen bei einem Wrapper zwei klassen Instanziert werden)?
Die Anpassungen für Partial dürften ja nicht so wild sein oder?
Ist es auch möglich einen Teil der Partial in einer anderen Assembly zu haben?
Kann man partial Klassen auch einfach stehen lassen ohne einer zweiten partial Klasse?
Besten Dank für Eure Meinung
antoschka
Hallo antoschka,
Schau mal hier: Partielle Klassendefinitionen (C#-Programmierhandbuch)
Wie würdet Ihr das im Vergleich zu einem von mir beschriebenen Wrapper bewerten (auch im Hinblick auf Performance, schließlich müssen bei einem Wrapper zwei klassen Instanziert werden)? Besser als Wrapper, denn partial Klassen sind EIN Typ. Der Compiler nimmt alle Teile und setzt sie zu einer Gesamtklasse zusammen.
Die Anpassungen für Partial dürften ja nicht so wild sein oder? Nee, einfach nur in der generierten Klasse ein "partial" in der Definition hinzufügen und die eigene Erweiterung in einer anderen Datei bekommt auch ein "partial". Es ist sogar egal, in welche Datei die implementierten Interfaces und die eventuell geerbte Klasse gelistet werden.
Ist es auch möglich einen Teil der Partial in einer anderen Assembly zu haben? Das geht nicht, denn Typen können sich (meines Wissens) nicht über mehrere Assemblies erstrecken.
Kann man partial Klassen auch einfach stehen lassen ohne einer zweiten partial Klasse? Ja, das geht wiederum.
Mfg NeuroCoder
mhm ... zu langsam
Hallo antoschka,
Die Anpassungen für Partial dürften ja nicht so wild sein oder?
Wie weit sich der Klassengenerator anpassen lässt, kann ich dir nicht sagen.
Ist es auch möglich einen Teil der Partial in einer anderen Assembly zu haben?
Nein! partial teillt nur einen Typ auf zwei Quellcode-Dateien auf. Aber ein Typ kann und darf nicht zerteilt werden!
(Deshavue?)
Kann man partial Klassen auch einfach stehen lassen ohne einer zweiten partial Klasse?
Ja.
Gruß
Juy Juka
Als Möglichkeit sei noch genannt die Entities von einem Dictionary abzuleiten. Die Entity Basis Klasse kann den typisierten Zugriff dann theoretisch noch kontrollieren - und das Ganze könnte sich dann sehr leicht erweitern lassen (Stichwort dynamische Datenstrukturen).
O/R Mapper freut sich über Dictionary's evtl. auch 😉
Da ich, wieviele andere, den OR-Mapper schon selbst geschrieben hab, stand ich auch mal vor dem Problem. Ich hab das ganze dann über das schon beschriebende "partial" gelöst.
Vorteil: Ich hab einen Ordner "CR Classes" in dem alle generierten Klassen drinnenliege, den ich immer wieder ohne Probleme überschreiben kann.
Nebenan hab ich einen Ordner "CR Extensions" wo ich einfach nach Bedarf Klassen erweitere.
Ich hab auch schon angedacht evtl. ein "CR Overrides" zu schreiben und hab in Vorraussicht praktisch alles an Methoden und Eigenschaften als "protected virtual" declariert, sodass eine überschreibende Klasse volle Kontrolle übernehmen kann. (auch Dinge, die ich mit Partial nicht schaffe).
Nachteil:
Während des Codens irrsinnig anstrengend, weil ich hin und wieder über die "gehe zu definition" in die generierte Klasse springe und dann ohne es zu merken evtl. dort was ändere, was bei der nächsten Generierung wieder weg ist. Da muss man höllisch aufpassen.
Restlichen Vor- Nachteile von partial könnt ihr eh selbst nachlesen.
Die Sache mit dem partial erweist sich als problematisch. Ich habe die Assemblies:
-Entities (generierte Etities and Mapping)
-EntityAccess (Enthält einen ENtityManager, der den OR-Mapper kapselt und CRUD Methoden zur Verfügung stellt)
-EntityExtension (hier liegen meine Bisherigen ERweiterungen drin)
EntityAccess verweist auf Entities
EntityExtension verweist auf Entities und EntityAccess
Wenn ich jetzt Erweiterungsklassen aus EntityExtension in Partial-Klassen der Entities-Assembly umwandle, entsteht eine Ringabhängigkeit:
EntityAccess benötigt Entities und die Zusatzfunktionalitäten der Partial-Klassen benötigen EntityAccess.
Sollte ich also doch in der EntityExtension Wrapperklassen für Entites implementieren oder was könnte man noch machen?
Besten Dank für Eure Antworten antoschka
Hallo antoschka,
Warum muss Entity-Acces die Entity-Klassen kennen? Ist der O/R Mapper nicht generisch und kann eh mit allen Klassen umgehen?
Die anderen zwei Assemblies gehören (nach meinem Verständniss) ohne hin zusammen.
Falls du die Assembly-Aufteilun gbeibehalten willst, sind die Wrapper-Klassen vermutlich das sinnvolste.
Gruß
Juy Juka