Laden...

Objektinstanz zwischen Applikationen "teilen"

Erstellt von BThomas vor 4 Jahren Letzter Beitrag vor 4 Jahren 2.482 Views
B
BThomas Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren
Objektinstanz zwischen Applikationen "teilen"

Hi,

Meta:
zunächst einmal, ich treibe mich eigentlich eher mit C/C++ um und bin ein C#/.Net "Noob".
Es tut mir sehr leid wenn die Frage hier im Forum bereits thematisiert wurde, ich habe nichts passendes gefunden und auch im sonstigen Internet suche ich mir einen Wolf, bzw. finde keine funktionierenden Ansätze.

Problem:
Ein Netzwerkgerät (das ich gebastelt habe) soll aus C# angesprochen werden. [EDIT] Es kann sich jeweils nur ein PC mit dem Gerät verbinden und es kann nur eine Verbindung geöffnet werden.

Hierfür habe ich eine Klassenbibliothek als C#.dll geschrieben, welche eine GeräteInterface-Klasse beschreibt.

Es gibt eine WPF Applikation die diese .dll verwendet, das GeräteInterface instantisiert und eine erstes UI bereit stellt. Hier wird letztlich hauptsächlich die Verbindung verwaltet (und in Zukunft noch ein paar Basis-Funktionen).

Mein Ziel ist es jetzt, dass sich weitere WPF Applikationen mit dem ersten UI "verbinden" können und das GeräteInterface nutzen ohne die Verbindung selbst verwalten zu müssen. Läuft die erste UI nicht, müssen die "Client" Applikationen nicht lauffähig sein.

Frage:
Ist COM der richtige Ansatz für mein Problem? Was würdet ihr empfehlen?
Falls COM bereits der richtige Ansatz ist brauche ich etwas Hilfe bei der Umsetzung...
Was muss auf welcher Seite getan werden? Ich habe vieles probiert aber das war mehr trial and error als saubere Programmierung, darum die unspezifische Frage, bin ziemlich verwirrt um ehrlich zu sein....

Schonmal vielen Dank fürs lesen...

1.029 Beiträge seit 2010
vor 4 Jahren

Hi,

solange du mittels .NET mit .NET kommunizieren möchtest ist COM eigentlich generell der falsche Weg.

Dein Problem ist mir nicht ganz klar, da du noch nicht preisgegeben hast was das für ein Gerät ist bzw. wie es angesprochen wird.

Grundsätzlich gibt es ja hier die Möglichkeit, dass es entweder nur eine - oder beliebig viele Verbindungen zum Gerät separat hergestellt werden können.

Wenn letzteres zutrifft - besteht grundsätzlich die Möglichkeit ein UserControl zu erstellen, dass in anderen WPF-Projekten verwendet werden könnte. Falls jedoch ersteres der Fall ist - musst du dir etwas ausdenken - dann würdest du nämlich ggf. einen Service schreiben, der widerum über ein weiteres Projekt via UserControl gesteuert werden werden kann. (Inter Process Communication wäre dann hier ein guter Startpunkt)

LG

B
BThomas Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren

Hallo Taipi88,

bei dem Gerät handelt sich um einen WIFI Mikrocontroller der in einem "Roboter" verbaut ist.

Es kann sich jeweils nur ein PC mit dem dem Roboter verbinden und mit ihm kommunizieren.

Im Basis-UI wird die Verbindung mit dem Roboter hergestellt und die Low-Level Schnittstellen des Roboters können direkt angesprochen werden. In den "externen" Applikationen (die sich mit dem Basis-UI verbinden) finden sich dann komplexere Anwendungen die die Abstraktion der Basis-UI nutzen. Modularität steht hier klar im Vordergrund.

Service würde bedeuten dass das Interface im Hintergrund aktiv ist und sich die verschiedenen UIs sich dann alle mit der gleichen Instanz verbinden?

72 Beiträge seit 2015
vor 4 Jahren

Hallo BThomas,

Ich bin zufällig auf dein Thema gestoßen.

Wenn ich das richtig verstehe, geht es hier um die Kommunikation zwischen 2 getrennten Programmen.

Ein Programm ist mit dem Roboter verbunden und das andere Programm stellt die GUI.

Falls ich das richtig verstehe, wäre eine Kommunikation (wie mir erklärt wurde) über gRPC die beste Möglichkeit.

Mit freundlichen Grüßen, FankenDerStein.

B
BThomas Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren

Hallo FrankenDerStein,

ja, so kann man es in etwa sehen (beide Apps habe ein GUI).

Ich gucke mir gRPC mal an.

Danke für den Tipp.

1.029 Beiträge seit 2010
vor 4 Jahren

Hi,

wenn ich so drüber nachdenke ist in deinem Fall eigentlich kein wirklicher Service / separates Programm nötig wenn man's einfach halten möchte.

Grundlegend wäre es denkbar, dass du z.B. Folgendes machst:
a) Eine Library, die bei Verbindungsaufbau mit dem Roboter einen Mutex belegt
(Damit unterbindest du letztlich mehrfachen Verbindungsaufbau vom selben Rechner mit
mit deiner Library)
b) Eine Library mit einem WPF-UserControl, dass vorgenannte Library verwendet (einfach per Referenz)
c) Beliebig viele WPF-Programme, die auf vorgenannte Library verweisen und das UserControl zum Verbindungsaufbau nutzen (wobei ich persönlich wohl b) auslassen würde, da man doch je Anwendung eigentlich auch ein anderes Design hat)

Falls mehrere Programme gleichzeitig kommunizieren können sollten (was teils sicherlich sinnvoll sein kann) - wäre gRPC eine gangbare Lösung zur Kommunikation der Anwendungen untereinander.

Edit: UserControl und Service würde ich generell in separaten Libraries/Projekten halten. Man bindet sich nicht eine bestimmte UI 😉

B
BThomas Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren

Hi,

ich wollte nur mitteilen wie ich es jetzt gelöst haben.

RPC wäre der overkill für mich gewesen. Ich habe eine Master-Applikation die sich mit dem Roboter verbindet und die Client-Applikationen verbindet sich via TCP mit dem Master. Dort habe ich ein einfaches Protokoll definiert. Das finde ich sauberer.

Danke für eure Hilfe!

16.806 Beiträge seit 2008
vor 4 Jahren

Als Feedback: das ist totaler Käse.

Was Du Dir da gebastelt hast ist quasi das Rad neu zu erfinden, statt auf fertige Architekturen/Komponenten zu setzen.
Da Du das ganze so vermutlich auch nicht mit dem Hauch einer Security implementiert hast, ist das ganze dazu auch noch unsicher, nicht erweiterbar und komplett proprietär.

Hättest gRPC genommen, hätteste was ordentliches mit Zukunft gehabt und das Ganze vermutlich auch noch mit weniger Code umsetzbar gewesen.
Aber ja: leider muss man sich mit neuen Dingen manchmal einfach beschäftigen.

Für so eine lapidare Sache was eigenes zu basteln: das ist overkill (und fahrlässig).

M
368 Beiträge seit 2006
vor 4 Jahren

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

M
368 Beiträge seit 2006
vor 4 Jahren

Ich gucke mir gRPC mal an.

Die druckfrische Ausgabe des DNC-Magazins behandelt gRPC i.Z. mit ASP .NET Core 3.0: DNC - Ausgabe 44 (pdf)

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉