AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Spring-DI / DelegatedConstructor / Factory für Dummies
Thema durchsuchen
Ansicht
Themen-Optionen

Spring-DI / DelegatedConstructor / Factory für Dummies

Ein Thema von stahli · begonnen am 2. Feb 2012 · letzter Beitrag vom 15. Mär 2012
Antwort Antwort
Seite 1 von 3  1 23      
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#1

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 14. Feb 2012, 17:16
Besser und egal wie IFuhrpark intern aufgebaut und organisiert ist: IEinkauf fragt IFuhrpark.Leiter nach dem Bedarf an IKraftstoff.
Im wirklichen Leben ist das nicht das auch nicht so. Da bekommt die Einkaufsabteilung die Anweisung von den Fachabteilungen zu Beschaffung der benötigten Materialien in der benötigten Menge. Müsste die Einkaufsabteilung pollen, würden sich unsere Einkäufer sofort erschießen.
Jetzt wird es langsam mühsam, da Du ausweichst und partiell und sinnenstellend quotest.

Aus meiner Sicht sind meine Argumente auf dem Tisch und es lohnt sich für mich nicht, in die nächste Wiederholschleife zu gehen.

Nimm Dir die Zeit und schau Dir die von Stefan bereits erwähnte CleanCodeDeveloper-Seite an. Damit bekommst Du einen schönen Blick darauf, wie und nach welchen Regeln die "großen Jungs" spielen.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 12:46
Mein aktueller Meinungsstand:

Künftige Verwendung von Interfaces: UNBEDINGT!
Ebenso das Verbergen der Klassen-Units untereinander (im Regelfall).
Im Projekt sollen dann grundsätzlich nur die Schnittstellen bekannt sein.

Auf eine Verschachtelung von Objekten über deren Owner werde ich verzichten. Beziehungen untereinander werden über eine Property abgebildet, die die ID des referenzierten Objektes enthält.

Auf Spring werde ich (vorerst) verzichten und mir selbst eine "Factory" (oder wie müsste man das nennen?) bauen, die auf Anfrage Objekte erzeugt und deren Schnittstellen zurück liefert. Wird keine ID bei der Anforderung angegeben, wird eine neue erzeugt. Die ID besteht aus zwei Zeitstempeln und einem Zufallswert (Programmstartzeit und Now und Random) und dürfte damit weltweit nicht doppelt vorkommen und eindeutig nach der Erstellungsreihenfolge sortierbar sein (im Gegensatz zu einer GUID).
ID + Interface werden in einem Dictionary gespeichert (dadurch erhöht sich m.E. der RefCount).
Wird ein Interface eine gewisse Zeit nicht mehr abgerufen und der RefCount ist 1 wird es aus dem Dictionary entfernt (und das Objekt somit aufgelöst).

Ich könnte also sagen: IMyPerson := Factory.GetPerson(PersonId, InClubId);
Die Factory kümmert sich dann darum, die Objekte herauszusuchen bzw. ggf. zu erzeugen und ggf. die Verbindung zu anderen Objekten einzurichten und die Schnittstellen heraus zu geben.

Ich denke, das würde ich lieber selbst an zentraler Stelle regeln, anstatt Spring einzusetzen, von dem ich wenig verstehe.

Diesen Weg würde ich mir wünschen - wenn es so realisierbar ist. Ich könnte mir vorstellen, dass man damit sehr übersichtlich abeiten kann.


Weitere Überlegungen: (Ich bleibe mal hier im Thread, da das thematisch schon noch zusammen gehört.)

Die Daten jedes Objektes würden in einer einfachen DB gespeichert. Je Klasse eine Tabelle, je (mit Attribut gekennzeichneten) Property ein entsprechendes Feld. Die Tabellen können jederzeit anhand der Klassendefinition passend erzeugt werden.

Im Grunde wäre das ja schon ein kleiner ORM.

Oder sollte man dann doch lieber gleich zu mORMot oder DORM greifen und nicht alles neu erfinden? Aber die arbeiten wieder nicht mit Interfaces? Fragen über Fragen...

Letztlich geht es dann natürlich auch noch um die Datenbindung an die GUI. Bei meinem odControls habe ich alles fest verdrahtet. Jeder Tastendruck z.B. in einem odEdit hat sofort den Inhalt eines Propertys verändert. Es gibt also keine Transaktionen oder Prüfungen, die die Übergabe von Änderungen aus der GUI in die Datenebene kontrollieren.
Diesbezüglich muss ich mich dann doch mal genauer mit DSharp und LiveBinding auseinandersetzen.
Ich weiß, dass ich ohne ein Databinding nicht mehr arbeiten will. Wie genau, ist aber noch nicht entschieden.

Nachtrag: Die GUI-Controls müssten eigentlich eine ID und PropertyName zugewiesen bekommen und sich darauf hin aus der Factory das entsprechende Objekt abrufen und sich an dieses binden. An der Stelle wird man mit Interfaces sicher nicht weiter kommmen - oder? Oder kann die RTTI mit Interfaces genau wie mit Objekten umgehen?
Und wann sollen die GUI-Controls der Factory bescheid geben, dass die bereit gestellten Objekte/Interfaces wieder freigegeben werden können?
Oh Mann - sooo viele Fragen.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (15. Feb 2012 um 16:47 Uhr)
  Mit Zitat antworten Zitat
ConstantGardener

Registriert seit: 24. Jan 2006
Ort: Halberstadt
379 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 14:00
@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
Andreas Schachtner
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 14:39
@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.)
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
ConstantGardener

Registriert seit: 24. Jan 2006
Ort: Halberstadt
379 Beiträge
 
Delphi 10.4 Sydney
 
#5

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 18:54
@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.
Andreas Schachtner
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 19:37
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
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Mär 2012, 15:34
@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).
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
ConstantGardener

Registriert seit: 24. Jan 2006
Ort: Halberstadt
379 Beiträge
 
Delphi 10.4 Sydney
 
#8

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Mär 2012, 19:03
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
Andreas Schachtner
  Mit Zitat antworten Zitat
exilant

Registriert seit: 28. Jul 2006
134 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 15. Feb 2012, 14:21
Nimm Dir die Zeit und schau Dir die von Stefan bereits erwähnte CleanCodeDeveloper-Seite an. Damit bekommst Du einen schönen Blick darauf, wie und nach welchen Regeln die "großen Jungs" spielen.
Ich werde mit deiner Verachtung leben müssen und weiter als kleiner Junge jeden Tag Probleme lösen. Ich werde die Augen offenhalten und sehen, welche Werkzeuge es so gibt die mir das Leben leichter machen. Was cleancodedeveloper.de angeht:
Das mit den Armbändchen ist doch Satire, oder?
Anything, carried to the extreme, becomes insanity. (Exilant)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#10

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 16. Feb 2012, 05:49
Nimm Dir die Zeit und schau Dir die von Stefan bereits erwähnte CleanCodeDeveloper-Seite an. Damit bekommst Du einen schönen Blick darauf, wie und nach welchen Regeln die "großen Jungs" spielen.
Ich werde mit deiner Verachtung leben müssen und weiter als kleiner Junge jeden Tag Probleme lösen. Ich werde die Augen offenhalten und sehen, welche Werkzeuge es so gibt die mir das Leben leichter machen. Was cleancodedeveloper.de angeht:
Das mit den Armbändchen ist doch Satire, oder?
Wieder ein Bestätigung, warum Delphi Entwickler des öfteren mit einem müden Lächeln und einem "das gibt's noch?" abgetan werden.

P.S.: Ob du dir Armbändchen anziehst oder nicht, oder, wenn du Judo oder Karate machst, nen Gürtel umbindest, steht dir frei. Und auch, ob du dazulernen willst, oder nicht.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:30 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz