Hallo,

ich versuche seit einiger Zeit ein paar von meinen Programmen zwischen GUI und Businesslogik aufzutrennen. Da kommt man dann vermutlich um die Begriffe wie MVVM oder generell MV* Sachen nicht mehr herum. Mich hat das MVVM Modell irgendwie eher zugesagt. Ich muß zu zugeben, dass ich noch nicht soweit bin, dass ich irgendwie konform mit dem MVVM Modell bin. Fürs Erste versuche ich mal das Programm auf 3 Schichten (GUI, Verbindungsschicht zwischen GUI und Businesslogik, Businesslogik) aufzutrennen. Im Prinzip speichere ich die benötigten Daten der GUI Komponenten(TEdit.Text, TCombox.Itemindex,...) in der Verbindungsschicht um diese bei Bedarf weiterverbeiten zu können.
Da in in meinen Programmen aber öfters auch mal VirtualStringTree einsetze bin ich auf ein grundlegendes Dilemma für mich gestossen und hätte gerne Eure Expertenmeinung benötigt. Und zwar enthält der VST implizit die sämtliche Daten, die man dann mit "VSTIrgendwas.GetNodeData(Node)" aufruft. Bei mir ist es so, dass der VST-Node ein einfaches Datenrecord enthält. Doch irgendwie widerspricht es doch irgendwie meinem Verständnis, dass die GUI Komponente alle Daten beherbergt. Sollte es nicht eigentlich eher die darunterliegenden Schichten sein, die alle Daten enthalten und kennen?
Derzeit mache ich es so, dass ich bei OnChange Ereignis von VST den Record von aktuell ausgewählten Node in die Verbindungsschicht mitschicke.
Doch meine Frage ist, wir würde ihr das machen?

Das Standardkonzept beim VST sieht ja so aus:


D.h. Im Knoten-Record ist also nur ein Verweis auf das eigentliche Datenobjekt vorhanden, nichts weiter. Stärker trennen geht irgendwie nicht, denn irgendwie muss der VST ja auch wissen, was er anzeigen soll ...

Standard ist eigentlich mit Klassen zu arbeiten und in neueren Versionen der VirtualTrees von Hause aus mit Generics. Das Pointergeschubse mit Records ist schon lange veraltet, auch wenn es auch in der aktuellen Version noch geht.

Wenn man dort nur die Referenzen auf die Klassen ablegt, genügt es auch diese an die nächste Schicht zu übergeben. Man kann diese Objekte natürlich auch analog zu den sonstigen Events in Delphi einfach als TObject weiterreichen. In Zeiten von Generics sehe ich es aber nicht als Problem an, wenn die GUI den Typ der Datenklassen teilweise kennt solange damit nicht mehr gearbeitet wird als für die GUI nötig.

Eine andere Variante ist Datenklassen für die GUI anzulegen und für die Weiterverarbeitung darin Dateninterfaces abzulegen. Die GUI hält dann diese Interfacereferenzen als IGuiObjectCar um die für die Anzeige nötigen Daten zu holen und die Datenschicht kann sich mit Supports das dort nötige Interface holen. Dadurch bindet man die GUI aber schon wieder relativ fest an die Daten.

Deshalb gibt es bei mir normalerweise dedizierte GUI-Klassen, die dann von der Logikschicht der GUI gesteuert und gefüllt werden und von dort wird dann mit den "realen" Daten interagiert. Die GUI kennt also nur die GUI-Daten, die GUI-Logik kennt die GUI-Daten und die "realen" Daten und die Business-Logik kennt nur die "realen" Daten.

jaenicke hat folgendes geschrieben :

Standard ist eigentlich mit Klassen zu arbeiten und in neueren Versionen der VirtualTrees von Hause aus mit Generics. Das Pointergeschubse mit Records ist schon lange veraltet, auch wenn es auch in der aktuellen Version noch geht.

Hm, das muss ich mir dann mal anschauen und mein Vorgehen in meinen Hobby-Projekten ändern, das hört sich ja irgendwie schon sinnvoller an.

Aber mein Pointergeschubse mit den Records kommt ja näher an das ran, was Karen aktuell macht - ist also für die Lernphase im Umgang mit dem Teil nicht ganz verkehrt. Immer ein Schritt nach dem anderen.

Hallo,
schau mal hier www.delphipraxis.net...k-2.html#post1428830 dort wird das Thema auch behandelt.
mfg
Dietmar

Hey,

egal was ich für ein Projekt bearbeite ob kommerziell oder privat, geht es um Daten verwende ich In-Memory Tabellen die man als einfache CSV auf die Platte schreiben kann oder eine Datenbanklösung.
Darüber nachzudenken die Daten in irgendwelchen selbst erfundenen Datenstukturen zu parken um dann über lesen, schreiben und bearbeiten nachdenken zu müssen ist dann einfach nicht mehr nötig und ich kann mich mit der Bussinesslogik befassen.

Auch ein Baum lässt sich wunderbar in eine normale Tabelle schreiben, an eine visuelle Komponente hängen oder in den Daten nach Infos suchen.

Gausi hat folgendes geschrieben :

Das Standardkonzept beim VST sieht ja so aus: markieren Delphi-Quelltext     1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: TTreeData = record       fmyData : TMyData;     end;     PTreeData = ^TTreeData; // var     Node: PVirtualNode;     Data: PTreeData; begin     Node := aVST.FocusedNode; // oder sonst ein Knoten     Data := VST.GetNodeData(Node);     Data^.fmyData.DoSomething(); end; D.h. Im Knoten-Record ist also nur ein Verweis auf das eigentliche Datenobjekt vorhanden, nichts weiter. Stärker trennen geht irgendwie nicht, denn irgendwie muss der VST ja auch wissen, was er anzeigen soll ...

Achso, dann klar. Danke!

Sinspin hat folgendes geschrieben :

Hey, egal was ich für ein Projekt bearbeite ob kommerziell oder privat, geht es um Daten verwende ich In-Memory Tabellen die man als einfache CSV auf die Platte schreiben kann oder eine Datenbanklösung. Darüber nachzudenken die Daten in irgendwelchen selbst erfundenen Datenstukturen zu parken um dann über lesen, schreiben und bearbeiten nachdenken zu müssen ist dann einfach nicht mehr nötig und ich kann mich mit der Bussinesslogik befassen. Auch ein Baum lässt sich wunderbar in eine normale Tabelle schreiben, an eine visuelle Komponente hängen oder in den Daten nach Infos suchen.

Hallo und danke!
In-Memory Tabelle ist eine gute Idee!

Hallo an alle!
Ich möchte mich bei euch nochmal bedanken! Ihr habt mir sehr geholfen!