meine odControls - Preview

[mquadrat]

Unsere aktuell eingesetzten Bausteine sind doch noch sehr zurückhaltend.

Wir haben zwar ein Tool zur Code-Generierung der Klassen, das allerdings kaum bis gar nicht genutzt wird :-) Die Geschäftslogik steckt in Klassen mit einer gemeinsamen Basisklasse, die das Active Record - Pattern umsetzt. Jedes Objekt kann sich also selbstständig laden und speichern ohne Mapper. Eine entsprechende Listenklasse gibt es auch, allerdings noch ohne Generics, da für D2007 entwickelt. Die Anbindung an die GUI wird derzeit über manuell geschriebenen Glue-Code realisiert, wobei es für die Listenklassen Adapter gibt um sie mit Grid oder Combobox zu verbinden. Die Validierung wird ebenfalls als Adapter zwischen Control und Objekt realisiert. Constructor Injection für Abhängigkeiten wird verwendet, allerdings nicht automatisiert.

Zukünftig wird es eher in Richtung ORM gehen (wahrscheinlich Attribut oder XML basiertes Mapping). Dazu wird die Datenbindung entweder aus DSharp oder XE2 kommen. Als GUI-Pattern wird aller Vorausicht nach MVVM zum Einsatz kommen, sowie ein Convention-Over-Configuration Layer, der die Data-Bindings automatisch generiert. Dependency Injection entweder aus DSharp oder Spring oder was eigenes.

Aktuell bin ich noch am Ausprobieren, was ich wie haben will und welche Blöcke man von wo benutzen kann, so dass es am Ende ein halbwegs durchgängiges Konzept gibt.

[stahli]

Ich will mal wieder...

Zitat:

Wir haben zwar ein Tool zur Code-Generierung der Klassen, das allerdings kaum bis gar nicht genutzt wird

Warum nutzt Ihr den Codegenerator nicht? Man kann sich doch damit Stunden Arbeit sparen (vorausgesetzt, er arbeitet komfortabel und der Code ist flexibel bearbeitbar).

Zitat:

Die Geschäftslogik steckt in Klassen mit einer gemeinsamen Basisklasse, die das Active Record - Pattern umsetzt. Jedes Objekt kann sich also selbstständig laden und speichern ohne Mapper.

Wohin speichert Ihr? In eine SQL-Datenbank? Wie realisiert Ihr nachträgliche Änderungen der Datenstrukturen?

Zitat:

Eine entsprechende Listenklasse gibt es auch, allerdings noch ohne Generics, da für D2007 entwickelt.

Die Generics sparen ja nur Tipparbeit. Das fällt nicht in´s Gewicht, wenn man die Klassen automatisch generieren lässt. Im Gegenteil sind generische Klassen eher störend, wenn man die RTTI für die Serialisierung einsetzt, da die Vererbung dann immer von TObject erfolgt.

Zitat:

Die Anbindung an die GUI wird derzeit über manuell geschriebenen Glue-Code realisiert

Glue-Code für die Datenbindung ist bäh :wink: Jedenfalls würde ich das immer lieber direkt zur Designzeit im Objektinspektor erledigen.

Zitat:

Zukünftig wird es eher in Richtung ORM gehen (wahrscheinlich Attribut oder XML basiertes Mapping)

Und welcher ORM schwebt Dir vor? (Win32 setze ich mal voraus)

Zitat:

Dazu wird die Datenbindung entweder aus DSharp oder XE2 kommen. Als GUI-Pattern wird aller Vorausicht nach MVVM zum Einsatz kommen, sowie ein Convention-Over-Configuration Layer, der die Data-Bindings automatisch generiert. Dependency Injection entweder aus DSharp oder Spring oder was eigenes.

Wie ist denn das grundsätzlich mit DSharp + XE2? Angenommen ich schiebe in der Datenschicht eine Berechnung an, in die 10 Sekunden braucht und rekursiv dutzenden Objekteigenschaften ständig neue Werte zuweist. Wird dann jede Wertänderung in der GUI direkt abgebildet?
Bei meinen odControls wird die GUI erst veranlasst, sich neu zu zeichnen, wenn die Datenschicht mit der Neuberechnung fertig ist.
Daher kann ich mir auch eine Client-Server-Lösung vorstellen. Die Clients werden beauftragt, sich neu darzustellen, wenn der Server neue Daten vorliegen hat. Alle sichtbaren Controls zeichnen sich dann neu und rufen dafür ihre aktuellen Daten ab (genaue Lösungsansätze habe ich aber noch nicht).


Zu Deinen früheren Anmerkungen:

Du hattest Recht mit Deinem Hinweis auf den zu einfachen Klasseneditor. Ich merke das jetzt, da mein Projekt komplexer wird selbst. Ich werde also mal noch einen komfortableren Editor erstellen, der dann eine bessere Übersicht über die verfügbaren Klassen, Typen und Beziehungen bringt.



Es ist halt schade, wenn in dem Bereich jeder sein eigenes Süppchen kocht. Ich hätte ja gern auf eine vorhandene Lösung zurückgegriffen, aber habe leider nix passendes gefunden...

[mquadrat]

Ja, wir speichern in eine SQL-Datenbank (Firebird). Bei einer Änderung von Strukturen (sprich: neue Felder) werden die in den Tabellen und in den Objekten von Hand hinzugefügt. Ist kein wirklich großer Aufwand. Aktualisierung der Kunden-Datenbanken über Delta-Listen.

Generics fallen imho extrem ins Gewicht. Je komplexer die Geschäftslogik umso mehr. Wir haben tausende Casts in der Anwenung, die - theoretisch - auf einen Schlag weg wären. Erhöht die Lesbarkeit enorm.

Bislang habe ich in Delphi noch keinen ORM gefunden, der mir wirklich gefallen hat. Gute Ansätze, aber die Projekte schlafen nach nem halben Jahr meist ein. Mal schauen was Spring bringt. Ansonsten halt selber schreiben.

Im Endeffekt kommt es ja drauf an wann man die Notification schickt. Wäre also nicht sonderlich kompliziert ein BeginUpdate...EndUpdate einzubauen.

[Stevie]

So, ich hab mir das jetzt auch mal angeschaut - bin ich blind oder wo ist der Source Code?

Ich mein, nix gegen deine Videos, aber wo kann man das selber ausprobieren? Ich hab immer nen Problem, wenn mir jemand, der was programmiert hat, vorführt, wie doll das alles funktioniert, ohne dass ich es selber auf Herz und Nieren prüfen kann. Ist mir schon oft passiert - bei der Präsentation alle staunend da gesessen und hinterher geflucht, wenn mans selber benutzen musste. (nein, ich meine nicht FireMonkey :twisted:)

Zum Experten teile ich die Meinung von mquadrat. Da hätt ich auch den Interface Teil einer Unit schreiben können und der Experte erzeugt mir den Implementation Teil. Auch das Format scheint mir etwas eigenwillig. Schau dir mal ModelMaker an, damit kann man sowas auch machen, eventuell gibt das noch die eine oder andere Idee.

Die Controls an sich find ich prima. Allerdings erschließt sich mir noch nicht ganz, wie weit sie in das ganze System verflochten sind. Den Tree zum Auswählen der Eigenschaften find ich auch gut (muss ich mal in meine Bindings einbauen *g*). Woran macht er fest, welche Eigenschaften angezeigt werden? Nur die mit den Attributen?

Ein bisschen flau wurde mir ehrlich gesagt bei der Turnier Klasse, das sah mir sehr nach god object aus, in dem alles drin steckt.

Bei der Generierung der Klassen musste ich an code first denken.

@mquadrat: Gib mir ruhig Feedback, wenn die beim Einsatz von DSharp für dein Projekt noch was auffällt oder fehlt. Hab noch einiges auf meiner Todo Liste stehen, was DSharp angeht - nur zu wenig Zeit (und manchmal auch keine Lust *g*)

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1126492)

So, ich hab mir das jetzt auch mal angeschaut - bin ich blind oder wo ist der Source Code?
Ich mein, nix gegen deine Videos, aber wo kann man das selber ausprobieren? Ich hab immer nen Problem, wenn mir jemand, der was programmiert hat, vorführt, wie doll das alles funktioniert, ohne dass ich es selber auf Herz und Nieren prüfen kann. Ist mir schon oft passiert - bei der Präsentation alle staunend da gesessen und hinterher geflucht, wenn mans selber benutzen musste. (nein, ich meine nicht FireMonkey :twisted:)

Ich wollte erst einmal grundsätzlich sehen, was Ihr von der Lösung haltet. In der Form kannte ich bisher noch kein Framework.
Ich selbst komme mit dem aktuellen Stand schon sehr gut zurecht - geht aber vermutlich jedem Entwickler so ;-) Wenn ein breiteres Interesse bestanden hätte, hätte man natürlich noch einiges an der Benutzbarkeit optimieren können. So erweitere ich die Klassen nach und nach entsprechend Notwendigkeit und verfügbarer Zeit.
Ich schicke Dir mal einen Link zu einer Testversion per pn. Es gibt aber noch keinen Installer und keine Hilfe und es kann an einigen Stellen schon noch etwas hakeln.
In den Videobeispielen zu School-Projekt (Beitrag #6) sind die notwendigen Schritte erklärt. Es ist nicht sehr kompliziert, aber ein paar Dinge sind natürlich zu beachten.

Zitat:

Zitat von Stevie (Beitrag 1126492)

Zum Experten teile ich die Meinung von mquadrat. Da hätt ich auch den Interface Teil einer Unit schreiben können und der Experte erzeugt mir den Implementation Teil. Auch das Format scheint mir etwas eigenwillig.

Die Meinung teile ich inzwischen auch. Ich plane deshalb durchaus einen Editor, in dem man Klassen und Typen z.B. per ComboBox auswählen kann. Das wäre schon noch deutlich komfortabler, aber es geht erstmal auch mit dem Texteditor ganz gut. Einen UML-Designer plane ich definitiv nicht. Erstens wäre das zu aufwendig und ich will den die Klassendeklaration außerdem möglichst nah am Aufbau der zu erzeugenden Units halten.
Die cla-Datei stellt somit eine Übersicht über die erzeugten Units dar, allerdings nur auf die Daten bezogen.
Da die erzeugten Units auch die kompletten Referenzen der Datenobjekte aufeinander realisieren, würdest Du mit dem schreiben des interface-Teils nicht weit kommen. Der odExperte übernimmt da noch einiges mehr.

Zitat:

Zitat von Stevie (Beitrag 1126492)

Schau dir mal ModelMaker an, damit kann man sowas auch machen, eventuell gibt das noch die eine oder andere Idee.

Das stimmt. Wenn ich den gekannt hätte, hätte ich es vielleicht auch einmal damit versucht. Allerdings kann ich nicht wirklich beurteilen, wie flexibel das Ganze ist. Lassen sich die Klassen denn problemlos mit beliebigen Funktionen und Prozeduren erweitern und vor allem auch debuggen? Vielleicht teste ich das später einmal.
Meine Lösung ist natürlich optisch nicht so aufwendig, dafür lassen sich die erzeugten Klassen sehr flexibel erweitern und verändern.
Dazu ist das Speichern und Laden automatisch implementiert und es gibt eine Datenbindung an die Formulare (wobei es dafür natürlich nun auch andere Lösungen gibt).

Zitat:

Zitat von Stevie (Beitrag 1126492)

Die Controls an sich find ich prima. Allerdings erschließt sich mir noch nicht ganz, wie weit sie in das ganze System verflochten sind.

Was meinst Du? Ich nutze statt einem TEdit ein TodEdit usw. Die odControls enthalten ein TodDataSet, das eine Datenkomponente und den gewünschten PropertyName zugewiesen bekommt.
Die odDataSets werden über Änderungen in der Datenschicht informiert und veranlassen ihren Owner, sich neu zu zeichnen. Sicher könntest Du das noch geschickter lösen. :wink:

Zitat:

Zitat von Stevie (Beitrag 1126492)

Den Tree zum Auswählen der Eigenschaften find ich auch gut (muss ich mal in meine Bindings einbauen *g*). Woran macht er fest, welche Eigenschaften angezeigt werden? Nur die mit den Attributen?

Genau.

Zitat:

Zitat von Stevie (Beitrag 1126492)

Ein bisschen flau wurde mir ehrlich gesagt bei der Turnier Klasse, das sah mir sehr nach god object aus, in dem alles drin steckt.

Würde ich nicht so sagen. Das TournamentEvent-Objekt kennt die Sportart, den Ort und die Turniere und kann mit diesen umgehen.
Die genannten Objekte selbst haben wieder ihre eigenen Unterobjekte und eine eigene Geschäftslogik. Das ist doch ok, oder?

Zitat:

Zitat von Stevie (Beitrag 1126492)

Bei der Generierung der Klassen musste ich an code first denken.

Weiß nicht recht, kann sein...

[mquadrat]

ECO läuft / lief unter dem Stichwort "Model Driven Architecture". Da ist das theoretische Ziel, dass man das Verhalten des Systems modeliert. Dieses Verhaltensmodell wird dann ausgeführt. Damit hat man - theoretisch - gar kein Coding mehr. In der Realität scheitert aber das Modellieren oft an der Komplexität und begrenzten Aufnahmefähigkeit der Menschen ;) Der Grundgedanke leitet sich vom "klassischen" Application Life-Cycle Management ab. Dort wird in der Requirement-Phase mit sogenannten Domänen-Modellen gearbeitet. Könnte man nun diese Modelle direkt vewenden, wäre einiges an Zeit gespart. Zudem kann der Berater vor Ort direkt das Verhalten ändern, indem er das Modell ändert (ohne Ahnung von der Technik darunter zu haben). Der Hype um diese Entwicklungsmethode wurde inzwischen von dem Hype um agile Entwicklung abgelöst :D

[stahli]

Hi zusammen,

ich wollte gerade nochmal schauen, was ich damals hier verbrochen habe ;-) - habe aber schon zu gut entrümpelt...

Falls jemand die Videos (od*.wmv und School*.*) noch zugänglich gesichert haben sollte wäre es lieb, wenn ihr mir das mal zusenden würdet.
(Aber nicht den ganzen Keller umgraben, so wichtig ist das dann auch wieder nicht.)


Gruß
Stahli