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