![]() |
AW: Trennung von GUI und Logik
Warum der Umweg über eine separate StringList mit Assign? Man kann der Datenklasse doch auch direkt das Memo (bzw. dessen Property Strings) übergeben.
Delphi-Quellcode:
Funktioniert wunderbar, und man kann die Methode FillList auch für andere Zwecke nutzen, wenn man z.B. die Daten nicht in einem Memo haben will.
type
TData = class public procedure FillList(aStrings: tStrings); end; TForm2 = class(TForm) Memo1: TMemo; procedure FormCreate(Sender: TObject); private { Private-Deklarationen } aData: TData; public { Public-Deklarationen } end; var Form2: TForm2; implementation {$R *.dfm} { TData } procedure TData.FillList(aStrings: tStrings); begin aStrings.Add('eins'); aStrings.Add('zwei'); aStrings.Add('drei'); aStrings.Add('vier'); aStrings.Add('fünf'); end; procedure TForm2.FormCreate(Sender: TObject); begin aData := TData.Create; aData.FillList(Memo1.Lines); end; Für Fortschrittsanzeigen etc. könnte man z.B. mit Messages arbeiten (der Datenklasse übergibt man dann einmalig das Handle der MainForm, die die Nachrichten dann abarbeitet), oder man erstellt eigene Events mit passenden EventHandlern. Dann hat man im Code der Datenklasse regelmäßig etwas wie
Delphi-Quellcode:
wobei fOnProgress eine Variable vom Typ Procedure( parameterliste ) of Object ist, die in der MainForm implementiert ist und entsprechend zugewiesen wird.
if assigned(fOnProgress) then
fOnProgress(param1, param2, param3, ...); |
AW: Trennung von GUI und Logik
Na dann ergänze ich mal paar Ideen. Wirkt gerade alles sehr kompliziert.
Wo wir uns einige sind: Die Logik darf das Oberfläche nicht kennen und muss somit auch ohne Funktionieren. Die Oberfläche interessiert sich aber für neue und geänderte Daten, damit diese ggf. Dargestellt werden können. Die Geschäftsobjekte sollte es nun an einer Stelle im Quelltext geben. "single point of truth" Daher werfe ich mal eine DIY Lösung ein, welche mit Ereignissen arbeitet, welche die Logik zur Verfügung stellt. Der klassischen Ansatz "Observer Pattern". Vielleicht auch das "Publisher-Subscriber Pattern". Siehe auch: ![]() ![]() |
AW: Trennung von GUI und Logik
Zitat:
Dazu dann eine dumme(?) Frage: Gegeben sei eine Logik die mit Hilfe von Threads irgendwelche Daten bearbeitet.Innerhalb des Treads wird regelmäßig ein Postmessage mit dem aktuellen Stand der Bearbeitung abgesetzt. Was passiert, wenn die GUI diese Messages nicht kennt? Gruß K-H |
AW: Trennung von GUI und Logik
Zitat:
Zitat:
|
AW: Trennung von GUI und Logik
Seitdem ich viel mit Angular und RxJS mache weiß ich die Eleganz des Observer-Patterns erst richtig zu schätzen. Allerdings ist dort die GUI auch threadsafe, da müsste man in Delphi halt etwas aufpassen, machbar ist das aber auch.
|
AW: Trennung von GUI und Logik
Zitat:
als erste Anweisung nach dem begin das hier reinschreibt: ShowMemoryLeaksOnSHutdown := true; Dann Programm ausführen, die entsprechende Aktion aufrufen und Programm beenden. Kommt keine Meldungsbox beim Beeenden gibt's kein leak, kommt eine ist eines vorhanden. |
AW: Trennung von GUI und Logik
Hallo,
seit ein paar Tagen bin ich nun dabei, die hier vorgeschlagenen Methoden der Kommunikation zwischen GUI und Logik auszuprobieren. Dabei wird für mich immer deutlicher, dass eine absolute Trennung garnicht möglich ist, wenn die Logik während der Abarbeitung des Auftrages, der vom GUI erteilt wurde, Informationen an das GUI übermitteln bzw. Aktionen des GUI auslösen soll. Die absolute Trennung funktioniert doch eigentlich nur, wenn ausschließlich der Rückgabewert einer Funktion ausgewertet werden soll. Denn sowohl beim Absetzen von Windows-Messages als auch beim Feuern von Events muss die Logik doch wissen, wohin 'gezielt' werden soll, um eine bestimmte Aktion des GUI auszulösen. Wie soll das gehen, wenn Logik und GUI überhaupt nichts voneinander 'wissen'? Hier meine Implementierung eines Update - Events, das tadellos funktioniert. Die Deklaration in der Logik-Klasse sieht folgendermaßen aus:
Delphi-Quellcode:
So wird das Event in der Logik-Klasse ausgelöst:
type
TUpdateGUIEvent = procedure(Sender: TObject; index:Integer; s: string) of Object; TGlExLogic = Class private FUpdateGUI : TUpdateGUIEvent; Procedure UpdateGUI(Index:Integer; s: string); [...] public property OnUpdateGUI: TUpdateGUIEvent read FUpdateGUI write FUpdateGUI; End;
Delphi-Quellcode:
Die Implementierung im GUI sieht dann so aus:
Procedure TGlExLogic.UpdateGUI(Index:Integer; s :string);
begin If Assigned(FUpdateGUI) then begin FUpdateGUI(Self, Index, s); end; end;
Delphi-Quellcode:
Die Logik muss doch z. B.wissen, welche Parameter mitgegeben werden müssen, um bei einem bestimmten Control der Mainform ein Update auszuführen?! Es ist dann aber auch nie auszuschließen, das bei Änderung des GUI das eine oder andere nicht mehr funktioniert.procedure TGL4Mainform.FormCreate(Sender: TObject); begin GLMainLogic := TGlExLogic.create(self); GlMainLogic.OnUpdateGUI := UpDateGUI; end; Procedure TGL4Mainform.UpdateGUI(sender:TObject; Index:Integer; s :string); begin case index of 1: Memo1.Lines.Add(s); 2: Memo2.Lines.Add(s); 8: label8.caption := s; [...] usw. end; end; Da wird man wohl notgedrungen Kompromisse machen und von der reinen Lehre der OOP abweichen müssen. Oder habe ich da irgendwas nicht verstanden? :? Gruß LP PS: Die oder Das GUI? Nach den geltenden Regeln heißt es doch im Deutschen das Interface? Oder doch nicht?? |
AW: Trennung von GUI und Logik
.. die Oberfläche muss doch wissen, welches Element es updaten muss.
Das hat nicht zwingend etwas mit dem Wissen der Businesslogik zu tun. Wie das Ergebnis zustande kam, welches die Oberfläche aktualisieren muss darüber weiß die Oberfläche nichts. Ich weiß nicht, ob es nicht vielleicht sinnvoller wäre ein Ereignis pro GUI Element zu haben? Grüße Klaus |
AW: Trennung von GUI und Logik
Die Logikschicht muss oder gar darf von der Oberfläche nichts wissen. Im Übrigen kann es ihr ja auch egal sein, ob ein String jetzt in einem Label, einem Edit oder als ListBox-Item dargestellt wird. Sie stellt einfach nur Ereignisse zur Verfügung, an die sich die Darstellungsschicht einklinken kann oder auch nicht.
|
AW: Trennung von GUI und Logik
Zitat:
Zitat:
Muß die Logik sich darum kümmern was aus ihren Messages wird oder nicht? Gruß K-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 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 by Thomas Breitkreuz