Livebindings Pro Contra

[bernau]

Habe einiges gesucht und einiges gefunden. Aber so richtig erschliesst sich mir nicht der Sinn von Livebindings.


Habe auch einige Besipiele aus XE2 angesehen.

BindLookupVCLProject -> Kein Code vorhanden. Alles zusammengeklickt.

SynchControlsSampleProject -> Viele Verknüpfungen über den OI. Kaum Quellcode.


Ist das wirklich wünschenswert? Alles nur noch im OI zusammenklicken? Code ist doch viel übersichtlicher. Wenn ich große Projekte habe, kann ich doch kaum noch Fehler anständig finden.

[Sir Rufo]

Meinst du jetzt speziell die LiveBindings oder Binding generell?

[bernau]

Wenn du so fragst: Beides ;-)

[Sir Rufo]

Versuch mal mit einem Edit-Control den Form-Titel (Form.Caption) zu bearbeiten (nicht einfach nur setzen, sondern den aktuellen Wert anzeigen zu lassen und dann die Änderung synchron anzuzeigen)

Mit einem Bindung ist das mit ein paar Klicks erledigt.

Mit Code geht das auch (hier mal ein DSharp Beispiel)

Delphi-Quellcode:

procedure TForm1.FormCreate( Sender : TObject );
begin
  TBinding.Create( Self, 'Caption', Edit1, 'Text' );
end;

[mquadrat]

Gerade bei Code wird der Nutzen noch deutlicher. Normalerweise schreibt man haufenweise Glue-Code um die Daten von Objekten in die Controls und wieder zurück zu kriegen. Das nehmen einem die Bindings ab.

Schau dir doch am Besten mal ein paar Tutorials / Blog-Posts zu MVVM an (vorwiegend im .NET Umfeld benutzt). Da kann man sogar über Convention-Over-Configuration die Bindings automatisch erzeugen lassen. Coding = 0. :-D

[stahli]

Hallo bernau,

ich möchte ohne DataBinding nicht mehr arbeiten.

Vielmehr würde ich mir ein noch umfassenderes Framework wünschen, das mir viel notwendige Arbeit abnimmt. Letztlich möchte ich die Daten und Geschäftslogik in einer Schicht (oder in 2 Schichten) bearbeiten und dann eine GUI an diese Ebene(n) "anknüppern".

So hat man klar getrennte Ebenen und kann deutlich übersichtlicher arbeiten.

Irgendeine Berechnung läuft in der Geschäftslogik und wenn das fertig ist, aktualisiert die GUI ihre Darstellung (ohne dass man das bei der Programmierung explizit durchführen muss).

Wie dieses Framework am besten aufgebaut und die Datenbindung geregelt wird (insbesondere in Multi-Tier-Projekten), darüber würde ich gern noch mehr lernen und diskutieren.

Für lokale Anwendungen gibt es ja inzwischen einige Lösungen.
Und auch wenn man die Bindung nicht in der IDE festlegt sondern zur Laufzeit, ist das angenehmer und übersichtlicher als die Daten per Code zu transportieren (Edit.Text := Object.Name und das Ganze zurück).

Mit meinen odControls kann ich in diesem Bereich sehr gut arbeiten, aber für Multi-Tier-Projekte sehe ich noch keinen guten Ansatz. Ich will Dir nix aufschwatzen (zumal ich bei meinem Ansatz inzwischen auch einige Grenzen erkenne), aber Du könntest Dir hier mal das Video "school-02" ansehen.
Es sollte jedenfalls der Vorteil von Schichtentrennung und Datenbindung erkennbar werden...


EDIT:
Die Fehlersuche wird stark vereinfacht, da man sich nur noch innerhalb der Businesslogik bewegt wenn man die Abläufe nachvollzieht. Die Syncronisation der Formularcontrols bleibt an der Stelle außen vor (ich denke jedenfalls, dass das bei Live Bindings und DSharp auch so läuft).

[Stevie]

Mal wieder nen Thread nach meinem Geschmack ;)

Wie schon einige erwähnt haben, primärer Nutzen von data binding allgemein ist: man muss keinen extra Code für den Datentransport (im Sinne von, wie kommt der Vorname aus dem Edit in das TCustomer Object) schreiben. Somit entfällt nahezu jeglicher code behind (der Code, den man so üblicherweise in den diversen Control Events findet). Du kannst also hingehen zu Entwickler A, der sich besonders gut mit Oberflächen Design auskennt und ihm sagen, dass du eine Eingabemaske für Kundendaten brauchst. Der kloppt dann die ganzen Controls auf die Form, macht sie hübsch und ist fertig (kann man dann übrigens auch schon gut mit dummy daten als Mockup benutzen). Entwickler B entwickelt derweil die Business Logik, welche Daten sind Pflichtfelder, welche Plausibilitätsprüfungen müssen beim Speichern eines Kunden erfüllt werden, etc pp. Dazu ist zweifellos viel Disziplin und ein gutes Konzept notwendig und man muss sich von diesem - ich nenn ihn immer "klassischen Ansatz" (Controls auf die Form, Events reinklimpern, fertig) trennen.

Was gewinne ich nun dadurch?

Testbarkeit: Ich brauch nicht durch das Form oder die komplette Applikation klicken bis ich am Kundenform angekommen bin und eventuell einen Kunden eintragen, alle Fälle abdecken, etc sondern kann den Source von Entwickler B in einem Unit test testen, da er nix mit Button16 oder Edit34 am Hut hat. Kann alle Plausiprüfungen auf Korrektheit prüfen und vieles mehr.

Wiederverwendbarkeit: Ich brauch in nem anderen Projekt Kundendaten Validierung, aber ohne Oberflächenfirlefanz? Klar, hab ich ja schon, danke Entwickler B.

Austauschbarkeit: Jemandem fällt ein, dass FireMonkey ja viel geiler ist, oder DevExpress, TMS oder ka was Controls viel stylischer aussehen? Ok, stell halt die Eingabemaske von Entwickler A um und fettich.

Ganz klar, das allein erreiche ich nicht durch data binding. Und data binding ist auch nicht das ausschlaggebende. Beschriebene Trennung konnte ich auch schon in Delphi 7 oder früher machen - nur nicht so elegant!


So, und nun zu LiveBindings speziell. Imho sind die Kollegen bei Embarcadero da leider etwas über oder am Ziel vorbei geschossen. Es wurde viel Potenzial verschenkt (compile time safety für string basierte bindings - Fehlanzeige). Die Konfiguration ist leider mal wieder total im RAD Ansatz erstickt. Alles kann man sich zusammen klicken und stecken und hinterher steckt so viel Krempel in der dfm Datei wo keiner mehr nachvollziehen kann, warum oder ob irgendwas nicht funktioniert.

Ich hatte schonmal an anderer Stelle erwähnt: LiveBindings sind imho aus der Notwendigkeit heraus entstanden, für FireMonkey die DBControls Funktionalität nachzubauen. Dabei ist leider das Grundkonzept - nämlich *einfach* Daten von A nach B zu schieben - auf der Strecke geblieben. Wenn man in FireMonkey in nem StringGrid nen FishFacts Dataset anzeigen will, klappt das alles prima. Wenn ich die Daten noch in extra Edits und was weiß ich editieren will, auch. Aber da hörts auch schon mit der einfachen Bedienung auf. Die einfachen TBindExpressions haben keine Funktionalität, automatisch über die Änderung in einem Edit informiert zu werden. Das geht nur in den TBindLink Teilen. Und die arbeiten sehr ungern mit einfachen Datenobjekten oder ner TList<TCustomer> z.B.

Die DSharp Bindings sind auch nur aus der Notwendigkeit heraus entstanden, dass ich ein MVVM Framework bauen wollte, was aber zumindest für mich nur sehr schwer ohne data binding vorstellbar ist - dazu in Kürze übrigens mehr an gewohnter Stelle 8-)

Wen diese ganze Thematik interessiert, dem würde ich in der Tat, wie mquadrat schon erwähnte, empfehlen, sich einige speziell in WPF verbreitete Ansätze (vor allem dieses ominöse MVVM ;)) anzuschauen.

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1136735)

dass ich ein MVVM Framework bauen wollte, was aber zumindest für mich nur sehr schwer ohne data binding vorstellbar ist - dazu in Kürze übrigens mehr an gewohnter Stelle

:kiss:

[bernau]

Danke für die Infos. Dann frage ich mal weiter:

Geschäftslogik von der Eingabe zu trennen ist schon ne gute Idee. Aber kann ich mit Lifebindings auch Fehler nach aussen geben. Kann ich mit Lifebindings ein Editfeld mit einer anderen Farbe hinterlegen, wenn der Wert ausserhalb des gültigen Bereiches liegt?

[stahli]

Mit einer nackten Bindung (wie in meiner Lösung) nicht.

Es gibt aber auch Frameworks, die das ermöglichen.
DSharp kann so etwas wohl bereits (habe ich noch nicht konkret getestet), die LiveBindings aber m.W.n. nicht.

In meiner Lösung wird jede Änderung (jeder Tastendruck) sofort in die Datenebene geschrieben. Entsprechend wird auch dort geprüft, ob ein neuer Wert akzeptiert wird oder nicht.
Der Vorteil ist, dass in einem Bearbeitungsformular nicht Kopien von Daten erzeugt werden müssen und Änderungen nachher per OK-Button o.ä. in die Datenschicht geschickt werden. Es gibt also eine strickte Bindung.

Man kann es aber auch so lösen, dass der Client (bzw. die GUI-Controls) die Eingaben prüfen und erst in die Datenebene schreiben, wenn die Validierung positiv war.

Ich weiß nicht ob man generell sagen kann, was der bessere Weg ist. Das hängt vermutlich auch vom Einsatzzweck ab. Bei der strikten Bindung muss man eben weniger in der GUI definieren.

[Medium]

Solche Min- und Maxwertbehandlungen gehören imho auch eher in das anzeigende Control, nicht ins Binding. Also: Ableitung von TCustomEdit nehmen, und das Verhalten dort einbauen. Wenn man die Min und Max-Felder dann auch noch öffentlich hat, ließen die sich auch via Binding steuern :)

[stahli]

Solche statischen Prüfungen wie Min- und Maxwerte können natürlich im Control erfolgen (wie z.B. in einem SpinEdit).
Anders stellt sich die Frage bei komplexeren Prüfungen, die sich auf die existierenden Daten beziehen (z.B. Prüfung eines eingegebenen Kundennamens oder einer eMail-Adresse).

[Medium]

Das wäre irgendwie ja doch schon wieder Geschäftslogik, weil ggf. Funktionsrelevant.

[Uwe Raabe]

Was mich bei der geforderten strikten Trennung von GUI und Geschäftslogik stört: man muss teils komplexe Mechanismen implementieren um auf etwaige Verletzungen dieser Logik in der GUI angemessen zu reagieren. Es genügt ja nicht, einfach nur die Überprüfung in das Businessobjekt zu verlagern, sondern man muss in der GUI ja auch auf die jeweiligen Fehler unterschiedlich reagieren. Andernfalls hat man nur ein stumpfsinniges Eingabeformular, wo doch die intelligente Unterstützung des Benutzers bei der Eingabe eigentlich Standard ist. Dies unterscheidet schließlich eine dumme Anwendung von einer benutzerfreundlichen.

Code in Forms kann m.E. demnach auch bei vorhandener Datenbindung nicht völlig verschwinden. Wenn ich z.B. ein Eingabefeld blinken lassen will, dann macht es keinen Sinn, dies in der Businesslogik unterzubringen (die soll ja nichts über das Eingabefeld wissen). Das erfordert aber im Businessobjekt auch die Möglichkeit, eine detaillierte Fehlerreaktion einzuklinken. Die meisten Datenbindungs-Implementationen haben aber gerade in diesem Bereich noch erhebliche Lücken.

[Sir Rufo]

Also mE muss die GUI so dumm wie möglich sein, also sollte im Idealfall nur die reinen Controls beinhalten.

Das Binding ist dafür da, die Daten zwischen dem Control und dem Objekt auszutauschen und auch die Validierung vorzunehmen.
DSharp bietet da entsprechende ValidationRules.

Andernfalls wäre es ja nicht möglich, die GUI einfach so mal auszutauschen oder auch Tests unabhängig von der GUI auszuführen.

Zitat:

Zitat von bernau (Beitrag 1136807)

Danke für die Infos. Dann frage ich mal weiter:

Geschäftslogik von der Eingabe zu trennen ist schon ne gute Idee. Aber kann ich mit Lifebindings auch Fehler nach aussen geben. Kann ich mit Lifebindings ein Editfeld mit einer anderen Farbe hinterlegen, wenn der Wert ausserhalb des gültigen Bereiches liegt?

Mit DSharp kann man alle Properties eines Controls beeinflussen

Und für diese Fehler-Anzeige liefert DSharp auch ein schönes Beispiel mit

[bernau]

Die Trennung macht für mich nur dann sinn, wenn auch die Fehlerüberprüfung in die Logik mit hineinkommen würden, sodaß man wirklich keinen Code mehr im Formular benötigt. Dazu müssten schon neutrale Properties wie z.B. "Eingabefehler" in den verschiedenen Controls (am besten in TControl) vorhanden sein. Ein TEdit würde dann automatisch die Farbe ändern können, Buttons automatisch disabled etc. Ansonsten habe ich die Logik in zwei verschiedne Bereiche verteilt und das ist unübersichtlich.

[mquadrat]

Nehmen wir als Beispiel mal das blinken lassen. Das gehört zur GUI. Im ViewModel (falls man MVVM nutzt) würde nur eine Eigenschaft entsprechend gesetzt (z.B. Fehler). Wie eine Änderung der Eigenschaft "Fehler" visualisiert werden muss, muss man natürlich in der GUI festlegen und nicht in der Geschäftslogik. Dann hätte ich ja doch wieder gekoppelt. Dazu kommt, dass GUI A blinken kann, GUI B aber nicht.

Ist ein bisschen wirr geschrieben, aber ich denk man erkennt grob was ich eigentlich sagen wollte :D

@Trennung

Das Ziel der Trennung ist NICHT, dass im Form kein Code mehr stehen darf. Es darf nur kein funktionsrelevanter Code stehen.

[Sir Rufo]

Streng genommen besteht die GUI (bzw. die View) auch aus Code. Nur weil fast alle die VCL benutzen und wir keinen Code sehen ist er ja trotzdem da :)

Was die View zur Verfügung stellen soll (Edit-Felder, Combo-Boxen, Fehler-Indikatoren) und deren Namens-Konvention ist ja eine Absprache zwischen dem View-Entwickler und dem Model-Entwickler und kann somit als Schnittstelle gelten.

Das Bindung ist dann dafür da, diese Schnittstelle zu bedienen.

Wie die View das dann auf den Bildschirm bekommt bleibt der View dann überlassen.
Ob das blinkt, oder ein Bild angezeigt wird, oder der gesamte Bildschirm flackert ... egal.
Über das Binding gibt es eine entsprechende Rückmeldung (z.B. ein Boolean-Flag und den Fehler-Text) und die View kann das dann anzeigen wo sie möchte.

[webcss]

Zitat:

Zitat von Sir Rufo (Beitrag 1136853)

Was die View zur Verfügung stellen soll (Edit-Felder, Combo-Boxen, Fehler-Indikatoren) und deren Namens-Konvention ist ja eine Absprache zwischen dem View-Entwickler und dem Model-Entwickler und kann somit als Schnittstelle gelten.
...
Wie die View das dann auf den Bildschirm bekommt bleibt der View dann überlassen.
Ob das blinkt, oder ein Bild angezeigt wird, oder der gesamte Bildschirm flackert ... egal.
Über das Binding gibt es eine entsprechende Rückmeldung (z.B. ein Boolean-Flag und den Fehler-Text) und die View kann das dann anzeigen wo sie möchte.

+1 :thumb: vollkommen richtig!

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1136841)

Also mE muss die GUI so dumm wie möglich sein, also sollte im Idealfall nur die reinen Controls beinhalten.

Da bin ich halt anderer Meinung. Vielleicht ist das aber auch nur eine Frage unterschiedlicher Terminologie zwischen uns.

Zitat:

Zitat von Sir Rufo (Beitrag 1136841)

Das Binding ist dafür da, die Daten zwischen dem Control und dem Objekt auszutauschen und auch die Validierung vorzunehmen.

Da stimme ich mit dir überein.

Zitat:

Zitat von Sir Rufo (Beitrag 1136841)

DSharp bietet da entsprechende ValidationRules.

Ich hatte eh vor, mich bei nächster Gelegenheit etwas intensiver mit DSharp zu beschäftigen. Vielleicht habe ich ja bei der groben Übersicht noch das eine oder andere Feature übersehen.

Zitat:

Zitat von Sir Rufo (Beitrag 1136841)

Andernfalls wäre es ja nicht möglich, die GUI einfach so mal auszutauschen oder auch Tests unabhängig von der GUI auszuführen.

Nach meiner Erfahrung ist es eben gar nicht so einfach, eine GUI einfach so auszutauschen, wenn sie eben nicht einfach nur "dumm" ist. Dabei meine ich jetzt nicht die Validierung der Eingaben, die (falls nicht schon im Control selbst durchgeführt) sicher in die Geschäftslogik gehört, sondern die Vermittlung etwaiger Eingabefehler an den Benutzer. Es reicht mir eben nicht, bei einer Fehleingabe lediglich ein Fenster mit einer Fehlermeldung aufpoppen zu lassen, sondern ich will dem Benutzer auch die Korrektur dieses Fehlers so einfach wie möglich machen. Dazu muss ich deutlich mehr über die Art des Fehlers wissen, als bloß die Tatsache, daß einer aufgetreten ist.

GUI-Design ist eben doch etwas mehr, als nur Formular-Design. Wenn es also etwas mehr sein darf, als nur das stumpfe Ausfüllen von Formularfeldern, gehört dazu auch die dynamische Interaktion mit dem Benutzer. Diese wiederum ist so stark von den Controls auf dem Formular und ihrer Bedeutung abhängig, daß sie sicher nicht in die Businesslogik gehört. Natürlich kann man auch hier versuchen, den UI-Code von den Controls zu trennen, aber das führt in den meisten Fällen zu mehr Problemen als man damit löst. Dafür sind die verschiedenen GUI-Frameworks (VCL, FMX, Web usw.) doch zu unterschiedlich.

Ich stimme dir auch in Bezug auf die GUI-unabhängigen Tests zu, was aber sofort die Frage nach den verbleibenden GUI-Tests aufwirft (man nehme z.B. nur mal die TAB-Reihenfolge). Diese sollten konsequenterweise dann aber auch ohne reale Businessobjekte durchführbar sein. Das wäre dann wiederum die Domäne der Mocks (gibt's aber wohl auch in DSharp).

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

[Stevie]

Damit die DSharp Diskussionen nicht immer andere Threads verstopfen, hab ich mal einen Thread dafür eröffnet.

P.S. Der Delphi 2010 bug ist gefixt (patch für spring4d liegt im repository)

[mquadrat]

Zitat:

Zitat von neo4a (Beitrag 1136874)

Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc).

Also das war in meinen Augen - mit Verlaub - schon immer eine schwachsinnige Idee. Man verwendet eine objekt-orientierte Sprache um die Business Logik dann prozedural in einem RDBMS zu schreiben, das für sowas gar nicht gedacht ist?! StoredProcs taugen m.A. nach nur für's Number Crunching wenn das hin- und her der Daten den Ablauf nur verlangsamen würde.

Zitat:

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.

Der Ansatz war vielleicht vor 10 Jahren ausreichend. Spätestens mit dem Aufkommen von service-orientierten Architekturen war der überholt. Delphi war immer "aus einem Guß" und genau das dürfte hier das Problem gewesen sein. Java und .NET besteht aus vielen einzelnen Gruppen, die miteinander kommunizieren müssen. Somit ist das Prinzip der losen Kopplung dort eine Notwendigkeit aus der Struktur heraus. Gerade bei Java macht das vieles komplizierter, aber es erzwingt auch sich Gedanken für "moderne" Programmierung machen zu müsesen.

Zitat:

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.

Dem ist nichts hinzuzufügen ;) Für Anfänger aber sicher die Hölle :D Da lernt man ja meistens erstmal, dass Objekte / Klassen reale Elemente abbilden (das Fahrzeug <-> Auto Beispiel, kennt wohl jeder Anfänger). Inzwischen sind wir schon eine oder zwei Ebenen abstrakter.

[neo4a]

Zitat:

Zitat von mquadrat (Beitrag 1137177)

Zitat:

Zitat von neo4a (Beitrag 1136874)

Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc).

Also das war in meinen Augen - mit Verlaub - schon immer eine schwachsinnige Idee. Man verwendet eine objekt-orientierte Sprache um die Business Logik dann prozedural in einem RDBMS zu schreiben, das für sowas gar nicht gedacht ist?! StoredProcs taugen m.A. nach nur für's Number Crunching wenn das hin- und her der Daten den Ablauf nur verlangsamen würde.

Du hast mich da etwas aus dem Zusammenhang gequoted: Mir ging es nur darum zu zeigen, warum man eventuell bislang ganz gut auch ohne Binding auskommen konnte (ganz im Sinne des Thread-Titels).

BTW, gab es auch eine Reihe sehr guter Gründe, die Business-Logik in die DB zu verfrachten: Performance und konsistenter Daten-Zugriff bzw. Sicherheitsmodell und ein seinnerzeit noch sehr hoher Aufwand an Entwicklung und benötigter Hardware.

Zitat:

Zitat von mquadrat (Beitrag 1137177)

Zitat:

Zitat von neo4a (Beitrag 1136874)

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.

Der Ansatz war vielleicht vor 10 Jahren ausreichend.

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi? ;)

[mquadrat]

Zitat:

Zitat von neo4a (Beitrag 1137212)

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi? ;)

Legacy-Anwendungen und Faulheit :D

[neo4a]

Zitat:

Zitat von mquadrat (Beitrag 1137220)

Zitat:

Zitat von neo4a (Beitrag 1137212)

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi? ;)

Legacy-Anwendungen und Faulheit :D

Wessen Faulheit ist Schuld, dass es die nötigen Tools erst heutzutage gibt?! SCNR ;)

[jobo]

OT:

Zitat:

Zitat von mquadrat (Beitrag 1137177)

Zitat:

Zitat von neo4a (Beitrag 1136874)

Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc).

Also das war in meinen Augen - mit Verlaub - schon immer eine schwachsinnige Idee. Man verwendet eine objekt-orientierte Sprache um die Business Logik dann prozedural in einem RDBMS zu schreiben, das für sowas gar nicht gedacht ist?! StoredProcs taugen m.A. nach nur für's Number Crunching wenn das hin- und her der Daten den Ablauf nur verlangsamen würde.

Also die "Schwachsinns"-Formulierung halte ich für sehr unüberlegt.
Das Verfahren Business-Logik auf dem Server zu hinterlegen ensteht ja nicht aus dem Gedanken, Programmierparadigmen lupenrein umzusetzen.
Es geht schlicht um fehlerfreie und robuste Funktion. Und die hat berechtigterweise Vorrang gegenüber Clientprogrammierkonzepten.
Ein Server ist ein Server, selbst in einer Mehrschichtarchitektur, erst recht in einem sehr heterogenen System, find ich das sehr nutzbringend.
Natürlich sind durchgängige Programmiertechniken erstrebenswert, aber sie haben nicht den Stellenwert einer zentralen und robusten Businesslogik.

Hinzu kommen Performanceaspekte, die für eine direkte Implementierung auf dem Server sprechen, deren Bedeutung allerdings je nach Last des Systems oft hinten angestellt werden können.

Eine leistungsfähige SQL- und Datenbankprogrammiersprache sind dafür natürlich ebenfalls wünschenswert. Aber das ist ja heute auch kein Thema mehr.

[hanspeter]

Bussines-Logik auf dem Server als Schwachsinn zu bezeichnen, halte ich auch für zumindest gewagt.
Technologien wie z.B. SOAP unterstützen die serverseitige Programmierung.
Wer sagt, das auf der Serverseite auf objectorientierte Programmierung verzichtet werden muss?
Wir verwenden stored procedure nur um einen Serverprozess zu starten und mit Parametern zu versorgen.
Moderne SQL Server lassen die Erstellung von SP mit beliebigen Programmiersprachen zu. (Firebird ab 3.0)
Wir nutzen die Technologie um auf den Server einen Verarbeitungsjob zu starten, der dann die eigentliche Verarbeitung vornimmt.
Der von der Datenbank aktivierte Steuerjob ist in der Lage Verarbeitungsprozesse mehrfach zu starten und auf eigene Threads zu verteilen.
Keine Oberfläche - im Eingang nur Datensätze aus der Datenbank und ausgangsseitig nur neue/modifizierte Datensätze in der Datenbank, da läßt sich der Test weitestgehend automatisieren.

Gruß
Peter

[mquadrat]

Ich habe nie behauptet, dass Business-Logik auf einem Server Schwachsinn wäre. Ich sagt, dass meiner Meinung nach Business-Logik komplett über StoredProcs zu fahren Schwachsinn ist. Auch wenn man die Möglichkeit hat UDFs in einer OOP-Sprache zu schreiben bleibt die Aufgabe des DB-Servers nun mal das Verwalten von Daten. Möchte ich einen App-Server dann spricht ja nichts dagegen einen echten App-Server einzusetzen. Also z.B. Tomcat, AppFabric oder was auch immer. Aber ein DBMS Zweck entfremden?