Databinding - Grundsatzdiskussion

[stahli]

Ich habe mich einige Zeit mit dem Databinding befasst und will mal ein paar Punkte zusammenfassen bzw. diskutieren:

- Grundsatz
Ich will auf jeden Fall künftig mit Trennung von GUI und Business-Logik arbeiten.
Das muss keinesfalls durch MVVM realisiert werden, aber eine Trennung soll gegeben sein und ein Framework soll sich um die Verdrahtung und den Datentransport kümmern.

- (Visual) Live Bindings von Emba (und FireMonkey)
Sind ja bekanntermaßen ziemlich fehlerhaft und in Bezug auf Datenmengen völlig untauglich.
Datasets werden komplett in Grids kopiert, was bei 100.000 Datensätzen bis 2 Minuten dauern kann (sowohl zur Designtime als auch zur Runtime).
Daten zur Designtime in einfachen Controls (z.B. Edits) werden im Formular gespeichert.
Beim Bearbeiten von Daten gibt es jede Menge Probleme.
Ebenso beim Arbeiten in der IDE, z.B. beim Ausschneiden angebundener Controls usw.

- OpenWire Live Bindings von MITOV (und FireMonkey)
Ist ähnlich den VLB von Emba. Graphisch aber deutlich ansprechender.
Man muss Controls bzw. deren Propertys "Pins" zuweisen und kann die Pins dann graphisch gestützt verbinden.
Am Anfang ist das sehr beeindruckend, aber ich hatte dann doch Zweifel, ob das das bessere Konzept ist. Unschön ist die Darstellung, wenn Controls nicht im Formular, sondern z.B. in einem Panel liegen.
Probleme bei Ausschneiden gebundener Controls gab es genau wie bei den VLB.
Die während der Designtime zugewiesenen Daten werden auch im Formular gespeichert.
Im Gegensatz zu dem VLB werden keine Exressions unterstützt, sondern nur die nackten Daten übertragen.
Dafür gibt es Clock-Pins, die z.B. Buttons an Methoden binden können.
Die Dataset-Bindung an Grids funktioniert (genau so ungünstig) wie bei den VLB (ob TMSFMXGrid unterstützt wird weiß ich nicht).

- Gitter von Hand füllen.
Testweise befülle ich ein TMSFMXGrid mit 100.000 Datensäten von Hand.
Das dauert geschätzt 1-2 Sekunden.
Bei beiden vorgenannten Datenbindungen dauert das 1-2 Minuten. Sicherlich macht sich dabei das genutzte RTTI bremsend bemerkbar.

- DSharp
MVVM finde ich zu kompliziert. Ich erkenne nicht, dass mir das einen wirklichen Vorteil bringt. Ich möchte so arbeiten, dass das flüssig von der Hand geht, also GUI basteln und mit der BL verdrahten - fertig. Das MVVM-Framework kann ich kaum nachvollziehen, weshalb ich damit auch nicht arbeiten werde.
Die IDE-Einbindung von DSharp (Verdrahtung zur Designtime) will ich mir heute endlich mal ansehen.
Was mir immer noch unklar ist, ist wie man Objekte binden kann, die von einem Server geholt werden. Zur Designtime liegen die ja dann noch nicht zum binden vor.
Auch würde mich interessieren, wie große Datenmengen (100.000 Datensätze) an ein Gitter gebunden werden. Wird da auch alles in einem Rutsch kopiert?

- TMSFMXGrid
Damit möchte ich am liebsten arbeiten, da ua. eine Gruppierung unterstützt wird, die Zellen sehr variabel formatierbar und Tabellenausdrucke möglich sind.

- Fazit
Für größere Datenmengen ist aber jede vorgenannte Datenbindung (bei DSharp weiß ich es noch nicht wirklich) eine unsinnige Lösung, da die Daten komplett in das Gitter kopiert werden und für jeden Schritt die (langsame) RTTI-Funktionalität ausgeführt wird.
Insofern wäre es weitaus sinnvoller, lediglich Rowcount und Colcount zu definieren und die Zellen dynamisch bei deren Darstellung und Bearbeitung an die Daten zu binden.
Wird eine Zelle gezeichnet, holt sie sich also ihren Wert vom Objekt oder dem Dataset ab und bei Änderungen schreibt sie diese entsprechend zurück.
Nur die sichtbaren Zellen würden Daten representieren.
Gruppieren ließen sich die Daten dennoch recht einfach. Man würde lediglich ab und zu Gruppenheader zwischen den normalen Zeilen einfügen.
Eine Umsortierung der Spalten im Gitter wäre natürlich schwierig, da ja nicht Daten von allen 100.000 Datensätzen vorliegen.
M.E. benötigt man somit unbedingt ein spezalisiertes Gitter, um Datenmengen (egal ob Objektlisten oder Datasets) sinnvoll daran binden zu können.
In dem Zusammenhang sollte dieses persistente Spalten unterstützen, denen sich bestimmte Formatierungen und Datenoptionen zuweisen lassen (hat das TMS Grid leider noch nicht).

[Stevie]

Wenn du z.B. den Virtual TreeView und den TreeViewPresenter benutzt, dann wird dir eine Liste mit 100000 Elementen in *fingerschnips* angezeigt (BeginUpdate/EndUpdate vorrausgesetzt, sollte die Liste beim Befüllen schon am Presenter hängen, da sonst für jedes Hinzufügen ein Event gefeuert wird, was dann "etwas" langsam werden kann - wir reden hier von Bereichen jenseits einiger Minuten).

Hängst du diese Liste an ein TStringGrid (was ja mit DSharp auch über ein CollectionView verfügt, wo du ItemsSource angeben kannst), dann wirds aber langsam, da dort dann pro Element die Texte in die entsprechenden Zellen kopiert werden. Geht vermutlich auch besser, denn TDBGrid kann das ja auch, da hab ich aber keine Resourcen reingesteckt - warum sollte man TStringGrid benutzen, wenn man was viel besseres benutzen kann (für viele Daten wohlgemerkt).

Und genau da liegt auch bei den LB der Hund begraben, über die entsprechenden Bind Expressions wird gesagt, dass der Text aus den Properties in die Cells gepackt werden soll und das wird dann für alle 100000 Elemente in der Liste gemacht, egal ob nur 10 sichtbar sind, wenn das Form aufgeht.

[stahli]

vorab @Stevie:
Der VTV ist mir irgendwie suspekt. Ich tendiere auch (derzeit noch) mehr zu FMX und dessen Gittern bzw. nur ListBoxen.
Deine Beispiele mit DSharp sagen mir auch nicht so richtig zu und es gab viele Fehlermeldungen unter XE3 (habe alle mal angetestet).
Mein Ansatz bzw. Wunsch wäre eine etwas andere Funktionsweise - daher ...


Noch ein paar Überlegungen zu DataBindings:


Wozu will man Datenbindungen haben?

Ich sehe zwei Gründe:

1) Ich möchte den Datentransfer mit möglichst wenig Quelltext abwickeln. Zum einen wegen Schreibfaulheit und zum anderen wegen einer übersichtlicheren Formularunit. Bestenfalls kann man die Beziehungen zur Designtime und vielleicht sogar graphisch herstellen.

2) Man kann wegen der Verwendung der PropertyNames Zuweisungen zur Laufzeit durchführen. Durch Einbeziehung der RTTI werden die Verbindungen dann zur Laufzeit quasi "interpretiert".

Diese "Interpretation" kostet jedoch ganz schön viel Zeit, so dass dieser Weg für sehr häufige Aktionen (große Datenmengen in Gitter) nicht wirklich sinnvoll ist.

Zudem werden im Hintergrund recht aufwendige und komplexe Funktionen durchgeführt, die eine gewisse Gefahr für die Stabilität eines Projektes darstellen können.

Offenbar wird in den LiveBindings auch nicht vernünftig geprüft, ob verbundene Objekte aktuell noch existieren. Löschen von Controls im Designer führen regelmäßig zu Zugriffsverletzungen.


Alternativen

Die Alternative wären Experten, die nach gewissen Vorgaben "einfachen" Quelltext für mich erzeugen, der dann (z.B. per include) in mein Projekt eingebunden und ganz normal kompiliert wird (ähnlich dem XML-Experten, DataSnap, TMS-DataModeler etc.).
Z.B. könnte so eine Bindung an ein Gitter realisiert werden, das zur Designtime in einem Designer konfiguriert wird (Spaltentypen, Darstellung, gebundene Felder usw.), der dann eine entsprechende Unit erstellt die dann im Projekt genutzt wird. Die Unit könnte dann bei Konfigurationsänderungen überschrieben werden. Man dürfte dann nur nichts händisch darin ändern oder müsste diese handischen Änderungen bei späteren Änderungen durch den Experten wieder neu berücksichtigen.

Das Anliegen, weniger Quelltext schreiben zu wollen, hätte man so auch erfüllt. Es würde relativ einfacher Quelltext vorliegen, der komplett compiliert würde, schnell wäre und im Handling keine Probleme machen würde.

Allerdings könnte man keine Testdaten zur Designtime binden, da der Datentransfer ja vom Hautprogramm realisiert würde.


Komponente

Wenn man den vom Experten erzeugten Quelltext dazu nutzen würde, davon eine eigene Komponente zu erzeugen (z.B. TPersonGrid) könnte das Grid auch zur Designtime dargestellt werden wenn bereits zur Designtime eine Datenmenge zugewiesen wird - wobei man davon nicht sehr viele Vorteile hätte.


Pro und Contra

Um die GUI-Controls untereinander zu verdrahten, wirkt ein Databinding im ersten Moment interessant. Allerdings spart das nicht wirklich viel Arbeit. Wenn ich in einem CheckBox-Click Edit1 und Edit2 auf Enable setze, brauche ich 2 Zeilen Quelltext. Im Fall eines Databindings muss ich 2 Controls bzw. Verbindungen einrichten (Bestenfalls graphisch).
Allerdings scheint in der Delphi-IDE aktuell kein DataBinding wirklich fehlerfrei zu funktionieren.

Einen wirklichen Nutzen sehe ich im Moment auch nicht darin, Datenmengen im ersten Schritt abzurufen, im zweiten Schritt eine Bindung an Controls zu veranlassen (mit Quelltext) und dann Daten wieder zu schreiben.

Sinnvoll wäre es, wenn die Controls „wüssten“, WAS sie darstellen sollen und sich das Framework um die Vermittlung kümmert.
Ein Edit soll z.B. die Eigenschaft „FirstName“ des Objektes „Person(1)“ bearbeiten. Das ist eine sinnvolle Definition. Nun muss das Edit bei einen zentralen Manager anfragen und die Person mit der Id 1 abrufen. Dann schaut es nach, ob die Person eine Eigenschaft „FirstName“ hat und bindet sich daran. Fertig. Das macht schon Sinn.
Weise ich
* einer ListBox -> „“PersonList“ + „FirstName“ oder
* einem Grid -> „PersonList“ + „FirstName, LastName, Birthday“ (so in´s unreine)
zu, dann müssen die Controls die Liste ebenfalls von einem Manager abrufen (wobei die Zeilendaten erst bereitgestellt werden sollten, wenn die jeweilige Zeile dargestellt wird).
Wo der Manager die Daten her bekommt (ob von einem Server, einem DataSet, einer Objektliste oder was auch immer) wäre dann egal.


Voraussetzung

Voraussetzung ist, dass die Controls auf die Zusammenarbeit mit dem Framework (Manager) abgestimmt werden. Entsprechend muss auch die Datenschicht den Manager kennen und ihn mindestens über Änderungen informieren.


Machbarkeit

Eine Realisierung bis hierher halte ich ohne große Schwierigkeiten für realisierbar. Unter der VCL habe ich mit meinen „odControls“ in der Weise bereits meine „Turniersoftware“ realisert.
Die Datenschicht ist über Objekte realisiert und die GUI wird in der beschriebenen Weise an die Datenschicht gebunden.
In der damaligen Version mussten die Objekte jedoch in der Hauptanwendung vorliegen. Es war nicht möglich, die Daten aus einer Datenbank oder von einem Server abzurufen.
Daher habe ich inzwischen bereits Ansätze einer Client/Server-Version angetestet.


Problem

Das größte Problem, welches ich derzeit sehe ist die Frage der Validierung.
Wenn Änderungen nicht sofort in der Datenschicht gespeichert werden sollen, muss deren Gültigkeit geprüft werden. Das kann sehr einfach erfolgen (z.B. ob ein Text kein ‚%‘ enthält) oder sehr komplex (ob einer einzutragende Person noch nicht im System mit 1MIo Datensätzen existiert).
Die erste Prüfung kann ggf. ein Edit selbst vornehmen, die zweite Prüfung müsste in der Datenschicht veranlasst werden.
In jedem Fall müssten die Controls aber die „fehlerhaften Daten“ erst mal anzeigen während sie im Formular eingegeben werden. Es darf also in dem Fall keine strikte Bindung in die Datenschicht erfolgen da ja sonst dort die falschen Daten gespeichert würden oder die GUI-Controls die Originaldaten aus der Datenschicht anzeigen würden (die Falscheingabe würde sofort überschrieben).
Also müsste ein temporärer Datenbestand (z.B. ein TPerson) erzeugt werden, das der aktuellen Datenbearbeitung dient.
Nach der Validierung können die Daten dann an die Datenschicht übertragen oder verworfen werden.
Im Firemonkey kann man auf Fehler schön hinweisen, indem die Controls rot umrahmt werden.

Das Handling einer solchen Validierung ist m.E. das größte (eigentlich einzige) Problem eines entsprechenden Frameworks.


Fazit

Die Controls sollten (ähnlich den früheren DB-Control) spezialisierte Controls sein, die zu einem DataBinding-Framework passen.
Die Controls sollten sich „gezielt“ Daten von einem Manager abrufen und ggf. untergeordnete Controls dynamisch erzeugen und binden.
Eine Bindung von GUI-Controls untereinander darf als Nebenprodukt möglich sein, aber als Ziel darf das keine Rolle spielen.
Die Controls sollten also nicht passiv auf das warten, was da kommt, sondern sich aktiv (über einen Manager“ ihre Daten abrufen.

Im Kern wird bei dem Konzept die RTTI für reine Datenübertragung genauso genutzt wie bei den LiveBindings, aber die Art der Datenbeschaffung unterscheidet sich.


Meinungen

?


PS: In folgendem Video habe ich noch ein paar Überlegungen dazu angestellt.
- Es ist zugegebener Maßen etwas wirr bzw. unstrukturiert, aber das Thema ist ja auch vielschichtig.
- Mit dem Video werde ich keine Preise gewinnen aber als Diskussionsgrundlage und zur Verdeutlichung meiner Vostellungen taugt es hoffentlich.
- Leider ist ist das Video deutlich länger geworden (45 min) als ursprünglich geplant.
- Ich zeige meine bisherigen Ansätze und erkläre auch (mit meinen Mitteln) wie ein DataBinding grundsätzlich funktioniert.
- Es wird hoffentlich deutlich, welchen anderen Ansatz ich von einem DataBinding erwarten würde.

[Furtbichler]

Ich denke nicht, das es ein Problem der Bindungsart ist, sondern eher darum geht, welche Controls man einerseits verwendet und welche Datenquelle andererseits.

Ungeachtet der Problematik, den Sinn bei 100.000 anzuzeigenden Datensätzen zu verstehen, ergibt sich das Problem, wie die Daten zum Client kommen. Bei 100k recs mag das noch einigermaßen gehen, aber wenn die Tabelle denn mal größer wird (Stichwort: Skalierbarkeit).

Hier ist eine Datenquelle, die die Daten nicht in Gänze, sondern on demand oder seitenweise lädt, das Mittel der Wahl.

Als ich mit Delphi programmiert habe (immerhin seit 17 Jahren), habe ich viel mit Datengittern gearbeitet und deine Probleme nie gehabt. Aber ich habe mir auch sehr früh ein ordentliches Control gekauft, damit ich eben damit keine Probleme habe. Das hat die Problematik der lahmen Controls gelöst.

Beim Paging habe ich es einfach anders gehandhabt: Niemand benötigt 100.000 Datensätze zum anzeigen. Punkt. Zum exportieren ja, von mir auch für Reports (wenn man denn die 1000 Seiten Jahresbericht wirklich haben will). Aber im Screen: Nee. Bisher konnte ich jeden (aber auch wirklich jeden) davon überzeugen. Und eine Suche, die 100k Treffer liefert, kann ich auch anders darstellen.

Aber wenn es denn sein muß, dann eben mit paging (eine Anwendung für eine Behörde).

Meine Erfahrung bezüglich der schwierigen Umgehensweise der VCL-Bindung kann ich einerseits bestätigen, aber andererseits habe ich mich -zumindest bewust- nicht mehr darüber geärgert, denn mit ein wenig Disziplin kann man die Eigenheiten umschiffen.

Da ich mich -gottseidank- nicht mehr mit Delphi auseinandersetzen muss, kann ich über das neue Zeugs nichts sagen.

Die o.g. Probleme (Controls, Datenquelle usw) sind auch auf C# übertragbar: Hier verwende ich DevExpress und bin vieles von dem Mumpitz los.

[stahli]

Also ich möchte schon beim Delphi bleiben und daher C# und .NET mal außen vor lassen.

Natürlich scrollt niemand 100T Datensätze. Aber nimm mal, die DP.
Wenn sie eine Formularanwendung wäre, hätte ich gern eine Tabelle mit allen Beiträgen. Dann kann ich scrollen soweit ich will und muss nicht blättern.

Wenn die Tabelle erst beim scrollen die weiteren Datensätze füllt ist das vom Transfervolumen ja unproblematisch und nix anderes als beim Blättern.

Bei Browseranwendungen ist das natürlich schon schwieriger zu realisieren (wir haben hier im Dienst so ein Exemplar, da kräuseln sich mir jedesmal die Fußnägel ), aber eine Listenbindung im Formular sollte das realisieren können.

Die LiveBindings kopieren aber den Datenbestand in die GUI-Controls (sogar auch in Gitter) und das ist vom Konzept her unschön bis Mumpitz.

Dass eine Anwendung Such- und Filtermöglichkeiten bieten muss ist klar, aber auch größere Datenmengen sollten konzeptionell händelbar sein.

[Stevie]

Zitat von stahli:

Die LiveBindings kopieren aber den Datenbestand in die GUI-Controls (sogar auch in Gitter) und das ist vom Konzept her unschön bis Mumpitz.

Das liegt, wie ich oben bereits erwähnte nicht an den LB an sich, sondern an dem StringGrid. Dieses arbeitet nicht virtuell sondern benötigt in den Zellen direkt den Inhalt. Siehe hierzu auch diesen SO Eintrag.

Außerdem bewegen wir uns bei der Diskussion Data Bindings auf verschiedenen Ebenen. Es gibt - ich nenn sie mal einfache und komplexe Bindings. Als Einfache könnte man ein Binding zwischen Edit und Vornamen einer Person, Checkbox und Enabled eines Buttons, etc bezeichnen. Diese sind vergleichbar mit einer einzeiligen Zuweisung (Person1.Vorname := Edit1.Text , Button1.Enabled := CheckBox1.Checked ). Dann gibt es komplexe Bindings, nämlich das Anzeigen von Datenmengen in Listboxes, Grids, u.ä. Diese lassen sich u.U. durch Kombination vieler einfacher Bindings realisieren (in den LiveBindings z.B. so getan).

Generell müssen Controls auch (fast) nichts davon wissen, dass sie "bindable" sind. Es muss lediglich eine Nachricht "mein Wert hat sich geändert" gesendet werden, auf welches ein Binding lauschen muss (Stichwort INotifyPropertyChanged). Eventuelle Validierungslogik etc kann dann irgendwo im Binding Prozess durchgeführt werden und dementsprechend reagiert werden (Nachricht an den Benutzer, Fokuswechsel verhindern, etc).

Von Experten, die datenspezifischen Code generieren, halte ich nicht viel, denn das ist im Grunde nix anderes, als eine automatisierte Verletzung des DRY Prinzips.

[Furtbichler]

Zitat von stahli:

Also ich möchte schon beim Delphi bleiben und daher C# und .NET mal außen vor lassen.

Klar, ich meinte nur, das sich viele Probleme der LB auf alle LB-fähigen Frameworks/Programmiersprachen erweitern lassen. Die DevExpress-Lösung (XPO) gibt es wohl auch für Delphi.

Zitat:

...hätte ich gern eine Tabelle mit allen Beiträgen....

Wozu? Nur um des Wollens Willen? Mit einer anderen Lösung wärst Du auch zufrieden. Filtern und Suchen ist viel wichtiger. Aber auch wenn die Forderung an sich Unsinn ist (imho), in einem hast Du Recht;

Zitat:

...auch größere Datenmengen sollten konzeptionell händelbar sein.

Zitat:

Die LiveBindings kopieren aber den Datenbestand

Wie Stevie schon erwähnte, ist das keine Eigenschaft der LB, sondern der Datenquelle. Ich möchte ihm wiedersprechen, denn man kann ein Stringgrid auch dazu bringen, Daten nachzuladen. Du musst die Scrollbars nur dazu bringen, sich genauso blöd zu verhalten, wie die von einem DBGrid und dann merkst Du den Unterschied erst gar nicht.

Das Problem bzw. dynamische Nachladen ist in meinen Augen eine Angelegenheit der Datenquelle. Wenn sie über ihre Schnittstelle nur die einschlägig bekannten Methoden 'First, Next, Prior, EOF und eventuell Goto' anbietet, kann man damit recht einfach eine komplett dynamische Geschichte realisieren. Vorne muss man eben nur dafür sorgen, das nicht benötigte Elemente (weil nicht sichtbar) nicht doch geladen werden.

Zitat:

Diese "Interpretation" kostet jedoch ganz schön viel Zeit,

Also nee, nicht wirklich. Du suchst Dir einmal anhand der Property das Objekt, an das zu binden ist und fertig.

Zitat:

Zudem werden im Hintergrund recht aufwendige und komplexe Funktionen durchgeführt,

Solange sie stabil sind (was sie irgendwann sind), ist das kein Problem. Ich habe keine Probleme mit den Bindings von C#.

Zitat:

Löschen von Controls im Designer führen regelmäßig zu Zugriffsverletzungen.

Das liegt dann wohl eher an der IDE.

[stahli]

Mit "LiveBindings" meine ich im Grunde das gesamte System, welches Delphi mitbringt, also die Bindings plus GUI-Controls incl. Gitter.
So soll der Nutzer ja schließlich arbeiten (können) und damit ist das für mich die Diskussionsgrundlage.

Workarounds hinten herum (die es geben mag) spielen hier erst mal eine untergeordnete Rolle. Ebenso, ob die problematische Gitterbindung am Gitter oder den LB liegt.
Es funktioniert nicht, Punkt.
Und selbst wenn es wie von Emba vorgesehen ohne ständige Fehlermeldungen funktionieren würde, wäre das Konzept mangelhaft.

Zitat von Furtbichler:

Zitat:

Löschen von Controls im Designer führen regelmäßig zu Zugriffsverletzungen.

Das liegt dann wohl eher an der IDE.

M.E. liegt es am Databinding. Die Bindings scheinen noch auf die (ehemals) gebundenen Controls zuzugreiefen, obwohl die nicht mehr existieren.
So habe ich die Probleme jedenfalls interpretiert (wobei ich auf genauere Untersuchungen dann keine zusätzliche Zeit verschwendet habe).
Das Löschen ungebundener Controls toleriert die IDE ja auch i.d.R.

[Furtbichler]

Ich gehe davon aus, das Du die aktuellsten 'Entwicklungen' bei Emba meinst. Da kann ich eh nicht mitreden, hört sich aber grauslich an.

Zitat von stahli:

Ebenso, ob die problematische Gitterbindung am Gitter oder den LB liegt.Es funktioniert nicht, Punkt.

Liegt weder an Grid noch an LB. Doppelpunkt.

[Stevie]

TStringGrid gibts nur, damit sie nen Haken auf der Featurematrix machen können, mehr ist das Teil nicht wert. Wer damit arbeitet, ist selber schuld.

Und ja, man kann das Teil pimpen, dass es so funktioniert, wie ein TDBGrid, das liegt aber daran, dass TDBGrid nicht von TStringGrid erbt, sondern die gemeinsame Basisklasse TCustomGrid oder so ist, die ungünstige Logik, die zu einem kompletten Befüllen führt, liegt im TStringGrid. Dass es nicht funktioniert, ist also falsch. Es funktioniert ja, ist nur "etwas" langsam mit großen Daten. Womit wir wieder bei meinem ersten Satz dieses Posts wären.