Interface- und Klassenstruktur für entkoppelte GUI und Anwendungslogik

[Aviator]

Naja es geht darum, dass für unterschiedliche Geräte unterschiedliche Werte abgerufen werden müssen. Diese Werte sollen aber auch anzeigbar und editierbar sein. Wenn aber nur die DLL selbst weiß, welche Werte vom Geräte abgerufen werden müssen, dann kann die GUI nichts anzeigen weil die Felder ja nicht existieren.

Also muss die DLL im Prinzip der GUI mitteilen, welche Felder vorhanden sein müssen und welche Werte diese haben.

Mit dem Ansatz den Ghostwalker mir geliefert hat, kann ich denke ich auch schon etwas anfangen. Zumindest versuche ich es mal.

Zitat von freimatz:

Ich gebe zu, dass ich das Problem kaum verstanden habe. Allerdings kann ich sagen dass bei uns nahezu alle Klassen auch ein Interface haben und Kontrakt und Implementierung zu trennen (und Referenzzählung zu haben).

Habt ihr denn auch eine GUI die sich abhängig von irgendwelchen Werten anpassen muss? Also neue Felder erstellen usw.? Das würde mich dann interessieren. Wie sieht so etwas bei euch aus?

Zitat von stahli:

Vielleicht hilft folgende Überlegung noch etwas weiter:

Die Geräte könnten auch Anweisungen für den Formularaufbau mitschicken (Edit1, an Position X/Y, gebunden an Wert Z; Button1, an Position X/Y, Beschriftung=OK, Action=SaveData)

Das wäre dann prinzipiell das, was Ghostwalker auch schon vorgeschlagen hatte. In die Richtung ging beim erster Gedanke auch schon, nur habe ich den im Ausgangspost nicht beschrieben um nicht irgendjemandem Worte in den Mund zu legen.

[Jumpy]

Wenn man eine Query über eine Datasource mit einem Grid verbindet, macht man ja mMn was ähnliches, das Grid hat die richtige Anzahl spalten und die Daten werden passend angezeigt. Vielleicht kann man sich da inspiration holen. Oder man tauscht die Daten zw. Anwendung und DLL JSON-artig aus und baut dann eine Adapterklasse, die daraus eine GUI machen kann.

[jobo]

Mir fällt bei den "Geräten" mit spezifischen Eigenschaften und DLL eher ein hierarchischer Key Value Store ein. Die DLL müsste also eine Art Baumstruktur liefern, z.b. in JSON oder so.
Visualisierung im Client dann z.B. mit (Virtual ) TreeView. Die Ebene eines Zweiges könnte dann ggf. als Form angezeigt/generiert werden.
Bei dem Ganzen müsste man vermutlich auch noch unterscheiden, welche Infos vom Gerät geliefert wurden/werden müssen und welche insgesamt definiert sind, also optionale Werte berücksichtigen. Das müsste spätestens die spezifische DLL wissen oder noch flexibler (bei neuer Firmware, ..), eine JSON Schema Definition.

[Aviator]

Das Ganze mit JSON abzuwickeln und dann daraus eine GUI zu bauen hat natürlich auch etwas. Vor allem bin ich dann etwas unabhängiger von der Programmiersprache in der die DLL entwickelt wird. Ist noch etwas flexibler als die Interface Lösung von Ghostwalker (mit der ich auch geliebäugelt hatte) denke ich. Hat sowas schon mal jemand von euch gemacht?

Wie würdet ihr dann den JSON String am besten von der DLL zur Anwendung übertragen? Einfach eine Funktion die einen string respektive PChar liefert, oder gibt es da andere Ansätze? ShareMem sollte nicht zum Einsatz kommen, da evtl. auch aus C# DLLs gelesen werden muss. Einen REST Service oder so pro DLL erstellen zu müssen halte ich für überzogen. Eine Datei ablegen aus der wieder gelesen wird finde ich auch unschön. Das sollte schon alles im Memory passieren.

Bin für jede Idee dankbar.

[jobo]

Man könnte es vielleicht URL artig machen (ohne http server natürlich). Vgl Registry.
Adresse (bzw. Key) setzen und Wert oder Wert Liste abfragen. Damit könnte man sich in Unkenntnis der Struktur bis in jedes Blatt hangeln.
Je nach zu erwartendem Volumen auch einfach alles holen.
Technisch bräuchte man nur einen Datentyp, der JSON encoding respektiert bzw. man muss sich im Interface darauf einigen, wie der String am Ende zu handhaben ist.

[stahli]

Also wenn Du DLL´s verwendest kannst Du den Datenaustausch direkt ja nur über Interfaces realisieren. Die könnten natürlich eine String-Eigenschaft haben und dort den JSON-Text o.ä. beinhalten.

Wenn Du für die Gui dann VCL-Controls erzeugst ist natürlich die Datenrückgabe bei Änderungen noch nicht geklärt. Das wird sicherlich der schwierigste Part.


Ich verwende für einen ähnlichen Anwendungsfall zwischen Server und Clients (mit eigenen Controls) Sockets (asychrones FTP).
Hier findest Du zwei kurze Videos, die einen kleinen Einblick zeigen: https://www.delphipraxis.net/185623-...-controls.html
Die Datenübertragung ist hier dokumentiert: https://www.delphipraxis.net/190482-...ockettest.html
Im Prinzip werden nur Message-Objekte erstellt und einem Framework zur Übertragung übergeben.

In dem Fall könnten die Geräte mit dem Hauptprogramm direkt kommunizieren, ohne dass dafür Controller über eine DLL eingebunden werden müssen.

Direkt zur Nachnutzung kann ich Dir das nicht anbieten, da ich das gerade nochmal überarbeite. Bei Interesse kann ich Dir aber noch etwas zeigen und Teile bereitstellen.

[TiGü]

Zitat von Aviator:

Wie würdet ihr dann den JSON String am besten von der DLL zur Anwendung übertragen? Einfach eine Funktion die einen string respektive PChar liefert, oder gibt es da andere Ansätze?

Nehme den Typ WideString, dass kannst du dann problemlos in anderen Sprachen nutzen (C#/Visual C++ -> BSTR).

[Aviator]

Zitat von TiGü:

Zitat von Aviator:

Wie würdet ihr dann den JSON String am besten von der DLL zur Anwendung übertragen? Einfach eine Funktion die einen string respektive PChar liefert, oder gibt es da andere Ansätze?

Nehme den Typ WideString, dass kannst du dann problemlos in anderen Sprachen nutzen (C#/Visual C++ -> BSTR).

WideString hatte ich ausprobiert, als ich eine Funktion aus einer C# DLL aufrufen wollte. Die Funktionen in der C# DLL wurden mit dem Tool UnmanagedExports exportiert. Das hat aber alles nicht funktioniert. Bis ich auf PChar umgestellt hatte. Meine schlussendliche Lösung wie es funktioniert hatte war wie folgt (aus dem Kopf, kann also ein paar kleine Fehler enthalten).

Code:

return: [MarshalAs(UmanagedType.BStr)]
public string TestMethod()
{
    string s = "Test";
    return s;
}

function TestMethod: PChar; stdcall; external 'Test.dll'