Zitat:
Insbesondere wenn man mit Frames, Datenmodulen und/oder Visual Inheritance arbeitet ist das in der Regel unverzichtbar.
Ich kann jedenfalls gut darauf verzichten, hat mir oft genug Kopfzerbrechen gemacht.
In einem Main_Modules
Unit kann ich alles per Code zusammenfassen was gebraucht wird,
statt per Designer in der
DPR.
Visuelles Ableiten, oder das visuelle Verbinden von Form/Datenmodul versuche ich möglichst zu Vermeiden.
Bindings kann man per Runtime Code viel zuverlässiger und wartbarer machen.
Kommunikation kann man über Interfaces optimieren, oder noch besser über Events komplett entkoppeln, damit kann ich im Extremfall sogar mit 0 Form/DataModul Bindings auskommen.
Vorteil:
Main
DPR bleibt quasi leer, und kann auch mal sehr schnell neu angelegt werden (z.B. von 10.2.3 auf 10.3), damit man die aktuellsten
IDE-Settings mitnehmen kann.
Es könnte natürlich anders werden wenn man zig Fremdkomponenten mit zig Fremdphilosophien einbindet.
Genau deshalb habe ich möglichst alle Fremdkomponenten rausgeworfen, und entscheide mich sehr bewusst für einzelne Komponenten, statt immer gleich ein ganzes Sammelsurium vom KomponentenSets reinzuerfen, von denen man nur 5% benutzt.
In neuen Projekten nutze ich möglichst Delpi pur und nur direkt ladbare Libraries, wie meine eigene oder Spring4D.
Ein "unverzichtbar" sehe ich dabei gar nicht, seitdem ich das versuche sehr extrem zu enkoppeln kann ich ruhiger schlafen.
Ich möchte hier niemanden zu irgendwas überreden, nur mal miteinander austauschen welche alternative Konstruktionen es geben könnte, mit welchen Vor- und Nachteilen.
Ich verfeinere meine Philosophie und Strategien auch ständig, und versuche so optimal wie möglich zu arbeiten, deshalb sehe ich mir immer gerne andere, und neue Lösungsvorschläge an.
Ein "NUR DAS ist richtig" lasse ich dabei eher nicht gelten, dazu zeigt uns z.B. JavaScript, PHP und andere was mit alternativen, vormals belächelten Konzepten möglich sein kann.
Da sieht Delphi eher alt aus.