Spring-DI / DelegatedConstructor / Factory für Dummies

[ConstantGardener]

@stahli
...um die Verwirrung zu erhöhen schau dir auch mal das ORM (TMS Aurelius) von TMS Software an. Ist zwar nicht kostenfrei (wenn man zumindest kommerziell entwickelt) aber hat durch den DataModeller und der Möglichkeit seine Klassen aus der vorhandenen Datenbank zu generieren auch seinen Reiz. Datenbanken werden schon einige unterstützt und es werden mehr. Auch die restlichen Features sehen ganz nett aus. Ich spiele gerade ein wenig damit rum und bisher gefällt mir was ich sehe.

cu cg

[stahli]

Zitat von ConstantGardener:

@stahli
...um die Verwirrung zu erhöhen schau dir auch mal das ORM (TMS Aurelius) von TMS Software an...

Da hoffe ich auf weniger Verwirrung und dann SOWAS!
Aber danke für die Info. Das sieht auf den ersten Blick sehr umfangreich aus. Werde ich mir mal die Tage anschauen...
(Der Kauf wäre notfalls machbar.)

[ConstantGardener]

@stahli

Das täuscht. Man kommt recht schnell zu Ergebnissen. Ich hatte mir ein kleines ORM auf Basis der neuen RTTI schon selbst gebastelt. Funktionierte auch recht gut (Spalten mit Attributen benennen, SQL aus diesen dann generieren usw.) und war als Training für RTTI super. Brunos Jungs habe hier aber schon einiges mehr aufgebaut (Linq-like-Syntax Querys usw.). Super ist auch die Unterstützung der verschiedenen DB's. Da bekommt man Lust auf mehr.

[stahli]

Ich meinte mit "umfangreich" nicht unbedingt "besonders kompliziert" sondern eher "viele Möglichkeiten". Auch gerade wegen der Linq-Syntax.

Vorhin habe ich nochmal schnell die Dokumentationen zum Aurelius und DataModeller durchgeblättert. Das scheint schon sehr leistungsfähig zu sein, ist aber zwangsläufig auch recht DB-lastig.
Ich meine, man muss sich auch mit den DB detailliert auseinandersetzen.

Nach meinen Überlegungen hätte ich aus den Klassen einfach vorläufige Tabellen generiert, in denen die Daten abgelegt werden (also keine direkten relationen Beziehungen, Trigger usw).
Man müsste sich also letztlich nur um die Klassen und Interfaces kümmern und die DB würde als reines (dummes) Datenlager dienen.

Natürlich ist so ein ausgewachsenes ORM deutlich leistungsfähiger.
Allerdings arbeitet man dann ja auch wieder mit Objekten. Würde das Aureliius-Framework klaglos ermöglichen, da Schnittstellen zu implementieren?
Auch möchte ich gern mit generischen Listen arbeiten. Harmoniert das dann?

Und letztlich ist mir wichtig, dass sich die GUI-Controls selbständig dynamisch die Objekte/Interfaces abrufen können, deren Daten sie binden sollen. Etwa so:

Delphi-Quellcode:

EditFirstName.Interface := IMyPerson;
EditFirstName.PropName := 'FirstName';

//oder auch

EditFirstName.Interface := IMyPlayer;
EditFirstName.PropName := 'Person.FirstName'; // wobei intern auf das Personenobjekt aufgelöst wird

In der Form nutze ich das bei meinen odControls und möchte das gern beibehalten.
Allerdings werden derzeit alle genutzen Datenobjekte dauerhaft im Speicher gehalten, was ich künftig nicht mehr will.

Vermeiden möchte ich, beim Öffnen eines Formulars dutzende Objekte/Interfaces zu erzeugen und die dann an die Formularcontrols zu binden.
Statt dessen weise ich lieber (wie auch jetzt schon) nur das oberste Objekt zu und das Framework kümmert sich darum, alle weiteren Subobjekte/Interfaces zu laden und an die Formularcontrols zu binden.

Ich werde wohl in nächster Zeit mal einige Varianten testen müssen, bin aber an allen Diskussionen zu diesem Bereich weiterhin brennend interessiert.

[stahli]

Zitat von ConstantGardener:

@stahli
...um die Verwirrung zu erhöhen schau dir auch mal das ORM (TMS Aurelius) von TMS Software an. Ist zwar nicht kostenfrei (wenn man zumindest kommerziell entwickelt) aber hat durch den DataModeller und der Möglichkeit seine Klassen aus der vorhandenen Datenbank zu generieren auch seinen Reiz. Datenbanken werden schon einige unterstützt und es werden mehr. Auch die restlichen Features sehen ganz nett aus. Ich spiele gerade ein wenig damit rum und bisher gefällt mir was ich sehe.

cu cg

Hi, kannst Du eine grundsätzliche Meinung äußern nach 4 Wochen herumspielen?

Insbesondere würde mich auch (wie unter #74 schon angedeutet) interessieren, wie die Möglichkeit der Arbeit mit Schnittstellen gegeben ist (bzw. wer die Objekte wie verwaltet) und wie man ggf. eine Datenbindung an die GUI realisieren kann (unter XE).

[ConstantGardener]

Hallo Stahli,

mein "rumspielen" wurde leider von anderen Aufgaben unterbrochen/gebremst. Und zwar so sehr, daß ich den 20% Rabatt-Termin bei tms verpasst habe.

Aber wie gesagt nette Sache dieses ORM und es tut sich noch einiges bei der Entwicklung aktuell Version 1.3. Du kannst das relativ einfach selber testen. Die Demoversion kannst Du ja normal runterladen und benutzen (nicht kommerziell). Einzige Einschränkung sind glaube ich die DataSet-Sachen. Die sind nur in der Vollversion drin. Und gerade das ist für dich wahrscheinlich interessant. Seit der letzten Version bieten Sie einen DataSet Nachfahren der intern die Objectlist einer Abfrage nach außen anbietet. Also Databinding mit DBControls --> intern komplette Objekte. Zumindest für Legacy Projekte super.
Schau dir mal das Music Beispiel an. Ich denke dann siehst Du wo der Hase langläuft.

cu cg