Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi class procedure, Singleton oder Instanz? (https://www.delphipraxis.net/174410-class-procedure-singleton-oder-instanz.html)

stahli 21. Apr 2013 16:43


class procedure, Singleton oder Instanz?
 
Liste der Anhänge anzeigen (Anzahl: 2)
Ich habe ein recht schwierig zu beschreibendes Problem.

Für mein Framework habe ich 2 Manager erstellt.

Zunächst einen BusinessLogic-Manager (BLManager), von dem im Projekt eine Instanz erzeugt werden soll.
Dieser erzeugt und verwaltet Businessobjekte in Listen und gibt die heraus.

Für die GUI-Controls gibt es einen GUI-Manager. Dieser wird ohne Instanziierung über Klassenfunktionen genutzt.
Die GUI-Controls melden sich bei Ihrer Erstellung (bzw. Laden der Formulare) dort an.

Der BLManager informiert den GUIManager über Änderungen. Der GUI-Manager beauftragt dann die Controls, sich neu zu zeichnen.

Das funktioniert wunderbar (bisher nur unter FMX), aber wenn ich Änderungen im Framework vornehme und das Package neu installiere, kann es zu Problemen kommen (Laufzeitfehler in IDE), wenn ich den BLManager im Mainform instanziiert habe. Führer ich die Instanziierung erst im OnCreate des Mainforms durch, dann gibt es das Problem nicht. Allerdings ist es natürlich schicker, eine BLManager-Komponente im Formular zu haben.

Bild 1 zeigt den Ablauf wenn kein Formular in der IDE geöffnet war und Bild 2 das Problem.

Ich habe nun mal untersucht, wo das Problem entsteht und die Abläufe der uses initialization und finalization sowie der class constructoren und class destructoren gelogt.
Wenn ein Formular in der IDE geöffnet ist oder war wurde ein BLManager instanziiert. Beim Installieren des Packages werden die Komponenten kurz entfernt und dann neu erzeugt.
Den zeitlichen Ablauf kann man ja nicht beeinflussen. Ich habe auch den Eindruck, dass die IDE seit XE sensibler auf das Installieren eines verwendeten Packages reagiert.

Ich habe schon einmal versucht, statt der statischen Klasse TssGUIManager ein Singleton zu verwenden. Das hat jedoch nichts verbessert.

Nun überlege ich, innerhalb einer TBLManager-Instanz eine TGUIManager-Instanz zu erzeugen. Diese würde dann mit aufgelöst, wenn der BLManager aufgelöst würde.
Die Listen, in denen sich die Controls registrieren müssten aber weitere über Klassenfunktionen erreichbar sein.

Der Vorteil der jetzigen Lösung ist, dass der GUIManager auch ohne Instanziierung funktioniert und eine Datenbindung der GUI-Controls sozusagen im Hintergrund ermöglicht.

Ich weiß, das ist ein schwer nachvollziehbares Problem, aber vielleicht hat ja jemand doch einen grundsätzlichen Rat?

Bjoerk 21. Apr 2013 22:08

AW: class procedure, Singleton oder Instanz?
 
Also, die Trennung von des GuiManagers und des BLManager würde ich schon beibehalten?

Man so ins Blaue: Ich würde vermuten, daß im Falle der Komponente Events ausgelöst werden, die Teile der GUI betreffen, die aber noch nicht erzeugt sind (im Unterschied zu OnCreate (beim Erzeugen))?

stahli 22. Apr 2013 20:32

AW: class procedure, Singleton oder Instanz?
 
Danke Bjoerk.

Ich werde es beim bisherigen Ansatz belassen.

Das Problem ist, dass sich schwer nachvollziehen lässt, wo es genau knallt.
Man kann zwar eigene Packages debugen, aber nicht deren Installation (jedenfalls kann ich das nicht).

Ich akzeptiere jetzt einfach als Einschränkung, dass der BLManager nicht zur Designtime in das Formular gesetzt werden darf wenn man noch am Framework arbeitet und dies ggf. neu installiert.
Statt dessen instanziiert man ihn im FormularCreate.
Delphi-Quellcode:
procedure TFormZipJob.FormCreate(Sender: TObject);
begin
  TZipJobBLManager.Create(Self);
end;
Dann gibt es das Problem nicht und es ist ja auch nicht wirklich mehr Arbeit.


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:44 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz