Laden...

Output von .NET-Programm A als Input für .NET Programm B nutzen

Erstellt von coventry vor 11 Jahren Letzter Beitrag vor 11 Jahren 2.309 Views
C
coventry Themenstarter:in
1 Beiträge seit 2012
vor 11 Jahren
Output von .NET-Programm A als Input für .NET Programm B nutzen

Hallo erstmal an alle 🙂

Ich beschäftige mich momentan damit, eine Lösung für das folgende Problem zu finden - nicht, weil ich gar nicht wüsste, was ich tun soll, sondern eher, weil ich gerne eure Meinung zur besten Lösung hätte.

Also, es geht um folgendes:

Ich habe ein .NET-Programm (genauer gesagt eine Simulation), welches als Ergebnis eine ziemlich lange List mit POCOs generiert. Lang ist relativ, es sind ein paar tausend Einträge, für manch anderes Gebiet mag das wenig sein. Die POCOs an sich haben nur ein paar wenige Felder mit Strings und double-Werten, nicht mehr als 10 pro Objekt. Eigentlich sind das nur "Datencontainer". Und davon stecken eben ein paar tausend Stück in der List, nachdem die Simulation durchgelaufen ist.

Und dann wäre da noch ein zweites .NET-Programm (XNA), welches den Output des Simulationsprogramms hernehmen und visualisieren soll. Mit Fake-Daten klappt das auch schon ganz prima.

Um das noch mal deutlich zu machen, es sind 2 getrennte Programme, und das hat so schon seinen Sinn. Ursprünglich war ich mir nicht sicher, ob ich die Visualisierung auch in .NET schreiben möchte - der Plan war zunächst, dass die Simulation ihr Ergebnis technologieunabhängig speichert (vielleicht in JSON oder so), damit die Visualisierung nicht davon abhängt.

Wie auch immer, jetzt sind beide Programme in .NET geschrieben und ich frage mich, wie ich die List aus der Simulation am besten an die XNA-Visualisierung übertrage. Trotz gleicher Technologie möchte ich die beiden Programme nicht zu einem "verschmelzen".

Jetzt stelle ich mir die Frage, wie ich das am besten lösen könnte. Was mir eben vorschwebte war, dass die Simulation ihren Output als File auf die Platte schreibt, quasi zwischenspeichert, und anschließend die XNA-Visualisierung gestartet wird, wobei der .exe der Pfad zum file übergeben wird. Das File könnte...*eine Textdatei oder ein binäres File sein... *...wobei man sich natürlich noch das Format überlegen müsste

  • denkbar wäre ein eigens erdachtes, textbasiertes und technologiebunabhängiges Format für mögliche Technologiewechsel in der Zukunft. Oder aber man nutzt einfach die .NET Serialisierung, was eventuell einfacher und performanter ist

Was sagt ihr dazu?
Gibt es vielleicht noch einen anderen Weg, den ich nicht bedacht habe, der aber gar nicht auf zwischengespeicherten Dateien basiert?

Über Antworten würde ich mich freuen, danke 🙂

C
1.214 Beiträge seit 2006
vor 11 Jahren

Naja, da wirds wahrscheinlich viele verschiedene Meinungen geben. Wenn du die Daten in einer Datei speichern willst, würde ich XML oder JSON nehmen (oder notfalls BSON). Dann hast du immer noch ein offenes/erweiterbares Format, dass du auch mit anderen Programmiersprachen und Technologien einlesen kannst.
Von irgendwelchen selbstdefinierten Formaten würde ich generell abraten. .NET Serialisierung bringt dir hier denk ich auch nichts. Ich würde eher auf ein sauberes Format achten, nicht auf irgendwas automatisch generiertes.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo Coder007,

da wirds wahrscheinlich viele verschiedene Meinungen geben.

glaub ich gar nicht mal. Sicher, wenn es um die Kommunikation von .NET-Programmen geht, kommen grundsätzlich alle möglichen Techniken der Interprozesskommunikation infrage. Aber wenn es darum geht, sich weiterhin die Möglichkeit offen zu halten, die Daten an ein mit einer anderen Technologie geschriebenes Programm zu übergeben, bleibt deutlich weniger übrig. Eigentlich nur TCP/IP oder eben Dateien. Und da sind die Dateien nochmal ein Stück einfacher und universeller.

Wenn du die Daten in einer Datei speichern willst, würde ich XML oder ...

Das "oder" würde ich auch weglassen. Gerade technologieübergreifend ist XML erste Wahl.

.NET Serialisierung bringt dir hier denk ich auch nichts.

Für die Kommunikation von zwei .NET-Programmen per Datei, würde ich .NET-Serialisierung sogar XML vorziehen. Aber mit Blick auf die Technologieunabhängigkeit scheidet .NET-Serialisierung in der Tat aus.

herbivore

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo coventry,

Eigentlich nur TCP/IP oder eben Dateien

wobei sich bei Dateien auch Memory Mapped Files anbieten.

Wenn du mit der XNA-Visualisierung noch nicht allzuweit fortgeschritten bist, so könnte Visualization Toolkit (VTK) ein passende Alternative für dich sein. Od. falls die Visualisierungssoftware nicht selbst geschrieben werden muss, so schau dir auch mal ParaView - Open Source Scientific Visualization an.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

M
171 Beiträge seit 2012
vor 11 Jahren

Ist es nicht ziemlich unperformant und auch Ressourcen verschwendend, Daten zwischen zwei Prozessen über das Dateisystem auszutauschen ? Ich finde das immer grausam, wenn ich sowas in (überwiegend) uralten Programmen vorfinde. Gerade wenn es ein wiederkehrender Datenverkehr ist, müssen hier auch noch Synchronisierungsmechanismen zusammen gefrickelt werden, damit niemand zu früh liest, während der andere noch schreibt ... bäh

Ich würde da zu einer simplen Übertragung per Networkstream tendieren. Wenn es beides .NET Programme sind, geht das sehr leicht mit TCPListener / TCPClient und wenn der Empfänger, also die Visualisierung doch irgendwann mit einer anderen Technologe realisiert wird, wird sich eine Zeichenfolge, die über einen Socket kommt nicht wirklich ändern.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo Mallett,

grundsätzlich stimme ich dir zu, dass man von Frickellösungen die Finger lassen sollte, insbesondere wenn man beide Programme schreibt und so freie Hand hat.

Auf der andere Seite habe ich die Frage so verstanden, dass die Daten von dem ersten Programm erstellt werden und von dem zweiten Programm erst weiterverarbeitet werden können und müssen, wenn das erste Programm fertig ist. Das wäre eine klassische Batchverarbeitung, die sich auch über eine Befehls-Datei (.cmd) oder ein makefile sehr sich leicht synchronisieren lässt, auch und gerade wenn man Dateien verwendet. Vielleicht ist eine Lösung mit Dateien dann sogar besser, z.B. wenn das erste Programm sehr aufwändig ist und das zweite Programm mit den gleichen Daten mehrfach bzw. zu unterschiedlichen Zeitpunkten aufgerufen wird. Bei einer Kommunikation von laufendem Programm zu laufendem Programm müsste sonst der erste Schritt [EDIT]unnötigerweise[/EDIT] immer wieder ausgeführt werden.

Es hängt also von den Umständen ab, was die beste Lösung ist. Eine Kommunikation über Dateien hat auch ihr Vorteile.

Da fällt mir ein: Eine Möglichkeit der (einfachen) direkten Kommunikation von zwei laufenden Programmen wurde bisher noch gar nicht genannt. Das wäre die Verwendung einer Pipe zum Übertragen der Daten. Damit meine ich, was man auf der Kommandozeile so schreiben würde:

pgm1 | pgm2

pgm1 schreibt dabei die Daten auf StandardOutput und pgm2 liest sie vom über die Pipe damit verbundenen StandardInput. Dadurch hat der Benutzer die Möglichkeit zu wählen, ob die Programme direkt kommunizieren sollen, wie im Beispiel. Oder ob er die Daten in eine Datei umlenken will (also in einer Datei zwischenspeichern möchte):

pgm1 > datei

um die dann zu einem beliebigen späten Zeitpunkt als Eingabe für pgm2 zu verwenden:

pgm2 < datei

herbivore

U
8 Beiträge seit 2012
vor 11 Jahren

Hallo Mallett,
mir gefällt dein Vorschlag mit TCPListener / TCPClient ebenfalls, da man so (falls gewünscht) die beiden Programme auch sehr einfach auf 2 separaten Rechnern laufen lassen kann, ein Punkt der hier glaube ich noch nicht angesprochen wurde.

Ich habe selber eine Visualisierung für eine Siemens S7 200 bzw. S7 1200 geschrieben. Wenn der Laptop direkt an der CPU hängt führe ich über 127.0.0.1 (local host) "Selbstgespräche", gleichzeitig kann ich aber auch ohne etwas am Quellcode zu ändern (nach Austausch der IP's) über das LAN oder Internet mit der S7 kommunizieren, sprich den Datenbaustein beschreiben oder Daten auslesen (aus dem Datenbaustein oder Input/Output Image). Funktioniert prima! Wenn man über das Internet kommuniziert sollte man seinen Stream verschlüsseln, aber das versteht sich eigentlich von selbst.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo thorsten982,

der Vorschlag TCP/IP zu verwenden, war von mir. 😃 Dass man dazu typischerweise die Klassen TcpListener und TcpClient verwendet, habe ich als bekannt oder leicht ermittelbar vorausgesetzt. Es steht z.B. im ersten Treffer bei der Google-Suche nach tcp/ip c#. Aber das nur am Rande. 😃

Und mit Dateien kann man die beiden Programme ebenfalls einfach auf zwei separaten Rechnern ausführen. Da dies asynchron passieren kann, also die beiden Programme nicht gleichzeitig auf beiden Rechnern gestartet sein müssen, könnte man es sogar als einfacher betrachten. Eine Datei über das Netz zu übertragen, kann je nach Konstellation ebenfalls einfacher sein, als eine TCP/IP-Verbindung trotz Firewalls und NAT aufzubauen. In einem lokalen Netzwerk würde man typischerweise einfach ein gemeinsames Netzlaufwerk verwenden. Auch bei der Übertragung über das Internet müsste man für die Verschlüsselung nichts extra implementieren, wenn man für die Dateiübertragung die Wege verwendet, die ohnehin standardmäßig verschlüsselt sind. Und derer gibt es viele einfache und bequeme.

Ich kann es nur noch einmal sagen. Es hängt von den Anforderungen und der Umgebung ab, welche Möglichkeit am günstigsten ist. Damit sage ich ausdrücklich nicht, dass Dateien besser sind, sondern nur, dass es von dem Kontext abhängt, was besser ist, insbesondere davon, ob nur ein Ergebnis produziert wird oder ob laufend Daten übertragen werden sollen.

herbivore

M
171 Beiträge seit 2012
vor 11 Jahren

Hallo herbiore,

ich verstehe bei Deiner Arguentation jedoch noch immer nicht, welchen Vorteil es haben soll, das Dateisystem als Zwischenebene zu verwenden.

Auf der andere Seite habe ich die Frage so verstanden, dass die Daten von dem ersten Programm erstellt werden und von dem zweiten Programm erst weiterverarbeitet werden können und müssen, wenn das erste Programm fertig ist.

Das habe ich auch so verstanden, aber wo ist das Problem ? Das zweite Programm wartet als reiner Datenkonsument auf über TCP eingehende Daten, bevor es zu arbeiten beginnt. Warum sollte dazu ein physikalischer Zugriff auf einen Datenträger, der dazwischen geschaltet ist, von Vorteil sein ?

Vielleicht ist eine Lösung mit Dateien dann sogar besser, z.B. wenn das erste Programm sehr aufwändig ist und das zweite Programm mit den gleichen Daten mehrfach bzw. zu unterschiedlichen Zeitpunkten aufgerufen wird. Bei einer Kommunikation von laufendem Programm zu laufendem Programm müsste sonst der erste Schritt [EDIT]unnötigerweise[/EDIT] immer wieder ausgeführt werden.

Gerade wenn der Schritt mehrfach ausgeführt werden muss, ist das mehrmalige Versenden über TCP noch effektiver als ein mehrmaliger Dateizugriff. Davon abgesehen, kann die Empfänger-Anwendung auch bei der ersten Übertragung die Daten zwischenspeichern, dann müss trotz mehrmaliger Verwendung die Daten nur genau einmal verschickt werden.

Es hängt also von den Umständen ab, was die beste Lösung ist. Eine Kommunikation über Dateien hat auch ihr Vorteile.

Ein Vorteil wäre es evtl. nur dann, wenn die Daten ohnehin gespeichert werden sollen (z.B. zur Nachbetrachtung), d.h. wenn das Speichern in einer wieder einlesbaren Datei Teil der Anforderung ist. Und selbst dann hätte man immer noch bei jeder Übertragung von Programm A zu Programm B einen überflüssigen Lesezugriff zu absolvieren.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo Mallett,

sorry, ich verstehe wiederum deine Argumentation nicht. Ich habe bereits geschrieben, welche Vorteile von Dateien ich sehe. Natürlich hat auch TCP/IP seine Vorteile. Deshalb war das auch einer meine Vorschläge. Dass ich mich danach auf die Möglichkeiten und Vorteile von Dateien konzentriert habe, liegt nur daran, das ihr bereits die Möglichkeiten und Vorteile von TCP/IP genannt hattet. Wenn du die Vorteile von Dateien nicht siehst oder sie dich nicht überzeugen, ok, dann entscheidest du dich eben anders. Ich habe ja gesagt, dass man das je nach Situation abwägen muss.

EDIT: Schon das reale Leben zeigt, dass es sowohl für synchrone Kommunikation (beide Kommunikationspartner kommunizieren zu gleichen Zeit, z.B. Telefon, Textchat oder eben TCP/IP) als auch für asynchrone Kommunikation (die Kommunikationspartner kommunizieren zeitversetzt, z.B. Anrufbeantworter, E-Mail oder eben Dateien) ein Bedarf besteht, dass keine der Kommunikationsformen geeignet ist, die andere vollständig zu ersetzen, und dass es auf die Situation oder Umstände ankommt, welche Kommunikationsform geeigneter ist.

herbivore

M
171 Beiträge seit 2012
vor 11 Jahren

Hab ich verstanden, mich htte nur interessiert, wie so eine Situation aussehen könnte, in der es einen Vorteil htte. Die von Dir genannten meinte ich entkräftigt zu haben.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo Mallett,

das meine ich nicht. Auf manche meiner Argumente bist du überhaupt nicht eingegangen, bei anderen gehen deine Gegenargumente an der Sache vorbei. Aber die Argumente sind genannt. Jeder kann sie sich nochmal in Ruhe zu Gemüte führen und sich dann eine eigene Meinung bilden.

EDIT: So wie man sich leicht eine Situation vorstellen kann, in der es besser ist, eine E-Mail zu schicken als anzurufen, ist es auch leicht, sich eine Situation vorzustellen, in der eine Kommunikation über Dateien günstiger ist als über TCP/IP. Andersherum natürlich genauso. Synchrone Kommunikation ist nicht in jeder Hinsicht besser als asynchrone und andersherum gilt das genauso. Deshalb wird es immer beides nebeneinander geben, je nachdem was sich für welchen Fall besser eignet.

herbivore