Databinding - Grundsatzdiskussion

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

[stahli]

Hier mal mein aktueller arbeitsstand: http://www.delphipraxis.net/173360-s...ml#post1204397