Ob die Kommunikation nun in einem eigenen Thread oder auch im Mainthread der Applikation laufen kann, kommt ja hauptsächlich drauf an, wie "blockierend" die Kommunikation an sich ist.
Aber die Kommunikation generell komplett von der
GUI zu trennen, ist schon einmal eine sehr gute Idee
Dann kannst du nacher auch die
GUI komplett austauschen, ohne dass du damit die Kommunikation beeinflusst.
Also den kommunkations-Code in eigene Klassen / Units kapseln oder auch in ein Datenmodul oder sowas in der Art, aber nicht in den Code der Form(s), denn das würdest du bald bereuen
Was meinst du eigentlich mit "wenn ein Gerät abstirbt"? Wenn die Kommunikation zusammenbricht? Das sollte generell mit der
GUI gar nichts zu tun haben, sondern das soll die Kommunkations-Klasse abfangen können und eventuell dann eine Nachricht an die
GUI senden können (oder die
GUI pollt den Status, je nachdem was du genau vorhast), aber nicht so, dass dann die
GUI abraucht
Ich habe so etwas auch schon einmal gemacht, ein Programm, dass drei Geräte überwacht.
Dazu habe ich mir erstmal die Kommunkations-Klasse für die Datenstrukturen und Befehle des Gerätetyps an sich geschrieben, im Programm dann selbst ein Datenmodul, das Instanzen dieser Geräte erzeugt / registriert und die Kommunkation der Geräte unter sich koordiniert. Die
GUI-Forms an sich empfangen und senden dann nur noch Events vom Datenmodul, sind also reine Anzeigen und Empfänger für Tastatur-Mausangaben, die aber an die Logik-Schicht übergeben werden, die dann wiederum die Events feuert usw.
Somit habe ich dann drei Teile, die einzeln wartbar sind:
1) Kommunkations-Klasse für das Geräte-Protokoll (Klasse)
2) Logik-Schicht, die die Geräte-Instanzen koordiniert (Datenmodul)
3)
GUI, die User-Eingaben annimmt und Meldungen anzeigt. (Forms)
Ausblick / Erweiterungen:
Was sich bei einer Geräte-Verwaltung nach meiner Erfahrung zudem noch anbietet, ist eine Art Scripting-
API für das Programm und dessen Events, vor Allem dann, wenn es sich bei der Software oder sogar dem Gerät selbst um einen Prototypen handelt, bei dem noch nicht alle Gegebenheiten klar sind.
Dann macht es Sinn, die Events und Funktionen von Kommunkations- Logik- und
GUI-Schicht, durch eine
API-Schnittstelle nach Aussen hin zugänglich zu machen und die Verbindungen über Scripting zu realisieren. Das hat den Vorteil, dass der Kunde teilweise selbst festlegen kann, was angezeigt / gemacht werden soll, wenn ein bestimmtes Ereignis eingetreten ist. Gute Erfahrungen habe ich hier mit Lua gemacht, für Delphi bietet sich aber wahrscheinlich PascalScript mehr an.