Livebindings Pro Contra

[Sir Rufo]

@Uwe

Wenn die View (GUI) sich einfach nur auf das Anzeigen konzentriert, dann kann ich diese View beliebig gegen eine andere austauschen, wenn diese sich an die Schnittstellen-Konventionen (Model<->View) hält.

Bei DSharp ist z.B. folgendes möglich:

Delphi-Quellcode:

TBinding.Create( Contact, 'Vorname', View, 'LabelVorname.Caption' );
TBinding.Create( Contact, 'Vorname', View, 'LabelVorname.Text' );

Wenn in der View ein Object (z.B. ein TControl) mit dem Namen "LabelVorname" gefunden wird und selbiges eine Eigenschaft "Caption" oder "Text" hat, dann wird der Wert von "Vorname" dorthin geschrieben.
So würde man z.B. die geänderte Namens-Konvention zwischen FMX, VCL und IntraWeb lösen.

Und die View darf ruhig dumm sein (sie darf sehr geschickt sein, die Daten zu präsentieren oder entgegenzunehmen) in Bezug auf Validierung oder Speicherung.
Auch ob das Edit-Feld x zum Zeitpunkt y aktiv oder inaktiv sein soll ist nicht Aufgabe der View, dieses alles steuert man über das Binding.

Und dann ist man durchaus in der Lage die View einfach so auszutauschen.

So würde ich die Abhängigkeiten sehen:

Code:

View <-> Binding ( = View-Logik) <-> ( Model-Logik <-> ) Model

[neo4a]

Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc). Arbeitete man nur mit DB-aware Controls, brauchte es auch keine Bindings.

Es kommt für mich gar nicht überraschend, dass (Live)Bindings erst jetzt bei Delphi ankommen, weil vor allem die spezielle Konstruktion der VgScene/FMX-Controls eine statische DB-Awarness unsinnig machen (VgScene als Vorläufer der FMX kennt auch deshalb schon Bindings). Zuvor war der Delphi-RAD-Ansatz mit VCL-DB-Controls völlig ausreichend und wir alle haben damit ja auch großartige Apps geschrieben. Und so hätte es auch bleiben können.

Will man aber nun mehrere Plattformen unterstützen oder einfach nur die schicken FMX-Controls nutzen und/oder testbaren Code schreiben und mit Mockups testen, dann kommt man mit den Alt-Ansatz allerdings nicht mehr so weit.

Mit DSharp-Bindings kann man sich sein Entwicklerleben schon erleichtern. Mit DI-Containern wie Spring4Delphi kann man herrlich modularisieren. Und wenn man (wie N.Hodge es fordert) nur noch gegen Interfaces programmiert und die Klassen-Definitionen nur noch im Implementation-Teil der Unit unterbringt, ist man schon ganz modern dabei.

Das alles ist nur noch zu toppen, durch ein MVVM-Ansatz. Die seit heute in DSharp verfügbaren Demos lassen einen schon ahnen, wohin die Reise geht. Da ist - dank Konventions-Logik - kaum noch Code in den Views und selbst in den nichtvisuellen Komponenten passiert nichts mehr. Allein durch die Benennung wird alles automatisch zusammen "geklickt". Ziemlich cool.

[Stevie]

Ich gebe Uwe recht, wenn es darum geht, dass bestimmte GUI Controls miteinander interagieren ("wähl ich hier X aus, wird dort Y eingeblendet"). Das wird im klassischen Ansatz oft alles auf ein Frame oder Form gepackt und lustig irgendwelche Sachen visible oder non visible gemacht. Oftmals werden aber auch - im Visual Studio user controls genannt - in Delphi würde ich Frames preferieren, benutzt. Generell bin ich aber der Meinung, dass nahezu jede Businesslogik ohne Oberfläche funktionieren muss.

Also angenommen, ich möchte aus verschiedene Zahlungsmethoden auswählen. Wähl ich Kreditkarte aus, werden die Controls für die relevanten Kreditkarten Infos eingeblendet (zusammen auf einem Usercontrol bzw Frame, im MVVM Jargon also z.b. KreditkartenView, evtl auch unterschiedliche je nach Kreditkarte), wähl ich Überweisung aus, muss ich ganz andere Daten ausfüllen, in dem Fall wird das ÜberweisungView angezeigt. Auch hier wieder, modulare Testbarkeit und Erweiterbarkeit. Hab ich irgendwo eine andere Stelle, wo ich Kreditkarten Infos anzeigen oder Editieren muss, zack, die View rein, fertig.

Bezüglich der Rückmeldung der UI auf eventuelle Validierungen, Pflichtfelder, sonstwas. Da kommt es in der Tat sehr stark darauf an, um was es sich handelt. Wenn generell ein Fehler auftrat, sagt das ViewModel (die Business Logik) einfach nur, dass und eventuell welcher Fehler auftrat. Und auf diese Fehler Information kann man sehr wohl die View wieder Binden. Wer sich DSharp anschaut, es gibt ein kleines Beispiel zu den Validierungen, wo ein kleines Icon eingeblendet wird, sobald ich einen nicht zulässigen Wert eingebe. Denkbar wäre auch eine Listbox oder ein Memo an die Liste der ValidationErrors zu hängen und dann seh ich, was alles fehlgeschlagen ist.

Der MVVM Ansatz von DSharp ist bei weitem noch nicht ausgereizt - wie schon im Blog vor einiger Zeit erwähnt, ich schau sehr stark bei Caliburn.Micro ab, weil ich das enorm gut finde - es gibt auch noch schwergewichtigere MVVM Frameworks (Prism z.B. - was übrigens nur den Namen mit der gleichnamigen Object Pascal Sprache für .Net von RemObjects gemeinsam hat). Aber ich hab ja auch gerade erst angefangen und viele Sachen werden auch erst klar, wenn man anfängt, damit eine Anwendung zu bauen.

Am Anfang erfordert diese ganze Denkweise etwas Einarbeitung, aber jeder, der auch durch .Net (speziell WPF) damit in Verbindung war, ist eigentlich begeistert. Großer Vorteil dort ist halt (noch), dass man dort durch das XAML sehr viel relativ elegant lösen kann, vor allem dadurch, dass viele Dinge, die man derzeit in Delphi nur string basiert machen kann (und demnach erst zur Laufzeit auftreten), dort zur design bzw compile time Fehler werfen.

[neo4a]

Ich habe mit Steves Unterstützung eine Kurzdoku für das D# MVVM Sample "ContactManager" zusammen gestellt.

Hier arbeiten die Bindings nicht explizit, sondern implizit durch Namens-Konventionen im Framework. Heraus kommt ein Projekt ohne Unit-Referenzen, hoch modular, mit konsequenter Trennung von GUI und Business-Logik und einer zusätzlichen Abstraktionsschicht bei der Datenbereitstellung.

[Stevie]

Kleine Warnung noch für alle Delphi 2010 User: leider gibt es dort in der RTTI nen Bug in TValue, welcher den Spring DI Container ziemlich alt aussehen lässt und dadurch nicht funktioniert (sprich AV beim starten). Ich bin gerade dabei, nen Workaround zu finden, aber aktuell siehts noch eher mau aus :?

[stahli]

Ich oute mich jetzt mal :duck:

Wie kann ich das Projekt denn nun eigentlich laden?

Ich habe mir TortoiseSVN installiert.
Jetzt dachte ich, ich lege in meinen Projekten einen Ordner DSharp an und muss über Rechtsklick Checkout eine URL zu dem Projekt angeben.
Aber welche URL? Ich finde da nur etwas von google aber nix DSharp.

Sorry, ich bin ein alter Mann und manchmal mit dem modernen Kram etwas überfordert ;-)

[neo4a]

Zitat:

Zitat von stahli (Beitrag 1136920)

Sorry, ich bin ein alter Mann und manchmal mit dem modernen Kram etwas überfordert ;-)

Reiss Dich zusammen ;)

DSharp
und
Spring4D

[stahli]

Ich bleibe gleich mal in diesem Thread.

Ich bekomme einen Fehler beim Download. Siehe Bild.
Kann das jemand nachvollziehen?
(Bin als Admin angemeldet.)

[Stevie]

SVN verschluckt sich manchmal, einfach nochmal probieren.

P.S. SVN und moderner Kram? :P

[stahli]

Oups, jetzt hat sich GData gemeldet:

Zitat:

Beim Schließen der Datei "D:\users\as\Documents\Projekte\DSharp\delphisorce ry\.svn\tmp\svn-F70CE90F" wurde der Virus "BehavesLike:BAT.Delete (Engine A)" entdeckt. Zugriff verweigert.
Beim Öffnen der Datei "D:\users\as\Documents\Projekte\DSharp\delphisorce ry\.svn\pristine\c3\c301d13c9e4e062aa40a8b5175df4e fc85b46f47.svn-base" wurde der Virus "BehavesLike:BAT.Delete (Engine A)" entdeckt. Zugriff verweigert.