meine odControls - Preview

[stahli]

Grundsätzliches:

Ich möchte Euch meine Komponenten vorstellen, mit denen man sowohl Datenklassen erstellen und ändern als auch Daten speichern und laden und letztlich diese auch mit minimalem Aufwand an die GUI anbinden kann.

Mein Anliegen war es insbesondere, eine flexible Programmierung zu ermöglichen und bei der eigentlichen Projekterstellung mit möglichst wenig Aufwand arbeiten zu können.
Dabei will ich komplett objektorientiert arbeiten (da dies m.E. die beste Flexibilität ermöglicht) und auch dem User (Endanwender) ein komplettes objektorientiertes Handling anbieten. Der User soll, wo immer es geht, Objekte sehen und diese bewegen können.

-> Video od1


Datenklassen - der odExperte:

Die odControls sollen dabei alle notwendigen Datenfunktionen selbständig initiieren und durchführen, so dass der Programmierer sich auf die Geschäftslogik (Methoden, Berechnungen etc.) und die GUI (Platzierung der Komponenten auf den Formularen beschränken kann.

Weiterhin sollen auch spätere Erweiterungen und Änderungen der Datenstruktur möglichst problemlos zu realisieren sein - und zwar direkt innerhalb der IDE.

-> Video od2


DataBinding:

Die Komponenten beinhalten ein DataBinding (allerdings nur untereinander, es können als nur die odData- an die odVisible-Controls gebunden werden). Andere Objekte lassen sich nicht an die odControls binden.

-> Video od3


Aussichten:

Es sind natürlich noch einige Erweiterungen und Verbesserungen geplant.
Insbesondere will ich versuchen, den odExperten noch besser in die DIE zu integrieren. Vor allem wäre es wünschenswert, die erzeugten Units automatisch in ein bestimmtes Package „einzuladen“. Ich werde versuchen, dieses Feature später zu realisieren.

Ein wesentlicher Nachteil der odControls ist, dass derzeit alle Daten komplett im Speicher verwaltet werden. Dies kann natürlich Probleme bei sehr großen Datenmengen verursachen (allerdings gibt es auch bei sehr großen Turnierveranstaltungen bisher keine Probleme) und es ist derzeit auch nicht möglich, die Daten von mehreren Clients aus gleichzeitig zu verwenden.

Zur Lösung der beiden Probleme habe ich bereits die Anbindung einer Datenbank vorgesehen. Diese soll jedoch lediglich als reines „Datenlager“ dienen. Einen OR-Mapper plane ich definitiv nicht. Die komplette Datenstruktur und Geschäftslogik soll auf jeden Fall weiter in den Datenobjekten verbleiben.

Die Datenbank würde dann lediglich die Objektstruktur, etwa:
-> ObjOwner, ObjClass, ObjId, Pos
und die Objektdaten, etwa:
-> ObjectId, PropName, PropValue
verwalten.

Ein alternativer/zusätzlicher Lösungsansatz könnte sein, die Daten auf einem „Server“ zu verwalten (der müsste in meinem Fall eine TodTournamentEvent bekommen), der alle Daten und die komplette Geschäftslogik beinhaltet und „GUI-Clients“ (ohne eigene Datenkomponeten) anzubinden, die die Objektdaten vom „Server“ bei Bedarf abrufen und Änderungen verschicken.
Es müssten immer nur diejenigen sichtbaren Controls Daten abrufen, die gerade gezeichnet werden. Nicht sichtbare Controls (z.B. in ausgeblendeten Registern oder Formularen) würden keinen Datentransfer verursachen.

Meine weiteren Verfahrensweisen und die genauen Implementierungen sind noch offen und auch davon abhängig, ob und wie weit Interesse von Euch oder Dritten besteht. Daher...


...meine Bitte:

Ich würde mich freuen, wenn Ihr Euch einmal die Zeit nehmt, euch die odControls (jedenfalls die Vorschauvideos) einmal anzuschauen.

Ich bin für jede Rückäußerung sehr dankbar, auch wenn Ihr das Konzept misslungen oder (für Euch) uninteressant findet.

Ich selbst werde mit Sicherheit weiter damit arbeiten (weil ich so einfach und flexibel bisher nicht entwickeln konnte), aber es interessiert mich natürlich dennoch sehr, was Ihr von den odControls haltet...

Also einfach drauf los



Und noch mal großen Dank an die gesamte DP!!!



EDIT: Weitere Beispielvideos im Beitrag #6

[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 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 )

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 von 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 )

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 von Stevie:

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 von Stevie:

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 von Stevie:

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.

Zitat von Stevie:

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 von Stevie:

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 von Stevie:

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

[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