sorgst Du gerade dafür, dass es weniger Argumente für einen Umstieg von Delphi auf .net gibt???
Naja, ich bin nach wie vor großer Fan von Delphi und wenn ich mir Dinge in .Net anschaue, bekomm ich immer Tränen in den Augen, was da so alles funktioniert.
Deshalb baue ich viele Sachen nach bzw versuche es. Und bei den meisten Dingen gelingt das auch (siehe meine anderen Posts in jüngerer Zeit).
Liegt daran, dass Delphi XE die erste Version ist, die nicht alle Nase lang die Generics (unerlässlich für das meiste, was ich veranstalte) auseinander fliegen lässt beim Kompilieren und halt die erweiterte
RTTI seit 2010.
Das DataBinding war ja immer ein Pro-Net-Argument. Jetzt würde dann eine Einrichtung der Bindings wohl nur noch in der Delphi-
IDE fehlen?
Plump gesagt ja. Es fehlen wie gesagt noch eine Menge Dinge für ein .Net vergleichbares Binding, aber der Grundstein ist
imho gelegt. Außerdem ist das ganze kein Selbstzweck, sondern ich ich brauchte die Bindings für andere Dinge (dazu später mehr). Ich hatte schon über eine Komponente (würde dann wahrscheinlich auf eine Art
BindingGroup Nachbau hinauslaufen) nachgedacht, die man auf Forms, Frames oder DataModules pappen kann.
Nach meiner (derzeitigen) Einschätzung wird die Binding-Option jedoch auch überbewertet, oder ist zumindest allein noch kein sehr wirksames Arbeitsmittel.
Sobald du Anwendungen schreibst, die einen Schwerpunkt auf Anzeige von Daten haben, willst du sie nicht mehr missen. Objektliste an ne Treeview gebunden, paar Einstellungen gemacht und bumm, werden die Daten angezeigt (und mit einigen mehr Handgriffen auch editierbar)
Wichtiger ist es m.E. Objekte leicht zu definieren und den Export/Import und Abfrage der Daten zu regeln.
Die Binding-Technologie ist sicher sehr interessant und hilfreich, aber eben nur ein Punkt bei der Arbeit mit Objekten.
Wie komfortabel die Objekte aber erzeugt und mit Daten gefüllt werden können, ist aber damit ja noch nicht gelöst. Ebenso nicht die Abfrage von Daten (Selektionen aus Listen).
Da wäre ein "LINQ to Objects" für Delphi sicher noch interessanter.
Gute Vorlage, auch sowas gibts schon, schau dir mal
Delphi Collections an. Eine weitaus mächtigere Collections library als das aus Generics.Collections.pas. Damit hast du eigentlich schon "LINQ to Objects" nur ohne die fancy build in Syntax wie in .Net. Du musst das dann halt über die Methoden aufrufen. Die fehlenden Lambda Ausdrücke machen die Code auf Delphi Seite natürlich ein bisschen länger als man ihn in C# schreiben kann, aber kurzer Quellcode war ja noch nie das Ziel von Delphi und ist
imho auch nicht schlimm.
Was darfs noch sein?
"LINQ to XML" vielleicht? Ein erster Prototyp von "LINQ to
SQL" (bzw eher ne Art Entity Framework "light" Nachbau) ist auch schon in der Mache, da haperts aber für die Generierung von vernünftigen
SQL Statements (abgesehen von nem full table select) noch etwas. Vor allem Mangels ExpressionTrees der delegates, die in .Net "einfach" in
SQL umgebaut werden. Bisher gehen einfache Abfragen aber komplette Codegenerierung für Datenklassen über Metadaten aus nem
SQL Server Datenbank Schema ist bereits implementiert.
Zitat:
Außerdem findet ihr in den benötigten Units noch weitere Dinge wie zum Beispiel Multicast Events oder den NotificationHandler, der dafür zuständig ist, dass die TBinding Objekte ohne Zutun freigegeben werden.
Berührt dieser Bereich ggf.
dieses Thema?
Ich weiß, mein Beitrag ist etwas unscharf gefasst - entspricht aber damit meinem derzeitigen Kenntnisstand des Themas
Bedingt, es geht eher darum, dass auch nicht von TComponent abgeleitete Objekte über die TComponent eigene Notification benachrichtigt werden, wenn sich dort etwas getan hat. So werden z.B. die Bindings freigegeben, wenn Source oder Target freigegeben werden (wenn sie von TComponent abgeleitet sind). Das heißt aber, dass wenigstens einer der Akteure ein TComponent sein muss, damit das funktioniert.
Außerdem hast Du eine Antwort verdient (auch wenn es eben erst mal nur solch eine ist)
Danke, ich beschäftige mich wohl mit zu komplizierten oder für die Community zu uninteressanten Dingen. Bin es gewohnt, fast kein Feedback zu bekommen.
(mimimi!) Schade eigentlich, in meinen Augen weitaus nützlichere Dinge als nen 64bit Compiler...
Vor allem, wenn es darum geht, moderne Software Entwicklung zu betreiben.
Der nächste "Delphi ist am Ende"-Thread steht bestimmt schon in den Startlöchern - kein Wunder 
PS: Wie (ungefähr) regelt eigentlich die
IDE selbst die Bearbeitung von Objekteigenschaften im Objektinspektor? Da muss ja eine ähnliche Bindung realisiert sein? Kann das jemand grob erklären?
Das geschieht über die published Properties der Objekte. Genau dafür wird die schon vor Delphi 2010 vorhandene
RTTI benutzt.
P.S.: Die von mir angeschnittenen Projekte und noch einiges andere sind Teil eines größeren MVVM Prototypens - natürlich auch fein bei .Net (inklusive diversen Codeplex Projekten) gespickt - die liefern halt gute Vorlagen.
