Laden...

Wie komplexes c# Datenobjekt über das Internet an c# Anwendung senden?

Erstellt von Unfug vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.022 Views
U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 3 Jahren
Wie komplexes c# Datenobjekt über das Internet an c# Anwendung senden?

Hallo zusammen,

ich brauche Hilfe bei einem Problem. Und zwar folgendes:

Ich habe eine Library welche mir bereitgestellt wurde.
In der Library (äußerst komplex und alt, aber inzwischen auch netstandard) wird ein C# Objekt erzeugt, dass ich in einer entfernten Anwendung benutzen muss.

--SERVER A erzeugt dieses Datenobjekt aus der Library. Das Datenobjekt wird durch unzählige Datenbank Abfragen und Service Anbindungen gefüllt. Das Datenobjekt wird in der Library auch dafür benutzt, dass bei Änderungen diese zurück in die Datenbank / Services fließen.

--SERVER B benötigt das erzeugte Datenobjekt für die Weiterverarbeitung.

Im Grunde muss ich also das Datenobjekt von A nach B transportieren und ggfs. auch zurücksenden.

Was habe ich bereits getestet:

  1. Das Datenobjekt in JSON umwandeln, um es über REST zu senden
    Fehlgeschlagen, da interne Propertys wie Dictionarys nicht in JSON umgewandelt werden können.

  2. Das Datenobjekt mittels BinaryFormatter serialiseren, um es als STREAM zu senden
    Fehlgeschlagen, da nicht alles als serializeable markiert.

  3. Ich dachte erst gRPC wäre eine Möglichkeit. Allerdings muss man hier ja die Datentypen (Messages) noch selbst aufbauen und das Datenobjekt ist zu komplex dafür. Es hat unzählige Properties, die unzählige NestedProperties haben. Also ich sag mal .klassisch Objektorientierung.

Hat jemand eine Idee wie man sowas lösen könnte? Ich kann/darf die Library nicht verändern.

Danke
Unfug

T
2.224 Beiträge seit 2008
vor 3 Jahren

Ich vermute stark, dass du nicht das gesamte Objekte mit allen internen Daten übertragen kannst.
Hier solltest du dich ggf. mit dem Hersteller in Verbindung setzen oder die Doku prüfen ob dieser Fall überhaupt möglich ist.
Wenn das Objekt interne Zustände hat, dann wird es vermutlich nicht möglich sein, das Objekt zu übertragen.
Aus Fall 1/2 hast du schon gemerkt, dass es nicht direkt machbar ist.
Brauchst du den das vollständige Objekt oder nur Teile davon?

Nachtrag:
Dein Fall 3 klingt nicht nach klassischem OOP.
Sondern nach einem zu komplexen Datenmonster.
Da es auch scheinbar interne Zustände hat, ist es auch kein reines Datentransferobjekt, was du in diesem Fall aber bräuchstest.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
441 Beiträge seit 2014
vor 3 Jahren

An sich ist es immer eine gute Idee die Kontrolle über das Datenobjekt zu haben, dass du zwischen Diensten hin und herschiebst.
Prinzipiell würde ich schauen, dass du ein Objekt erzeugst, dass alle Informationen enthält, die du in SERVER B benötigst und es dann aus dem Ergebnis der Bibliothek befüllen.

Alles andere kann unter Umständen auch lustige Nebenwirkungen haben, z.B. wenn es sich nicht um reines Datenobjekt handelt und darin Logik enthalten ist. Vor allem dann, wenn diese auf externe Ressourcen zugreift, die in SERVER B nicht verfügbar sind oder einen Verbindungsaufbau benötigen.

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 3 Jahren

Hallo zusammen,

ihr habt beide vollkommen recht und es ist auch genau wie ihr es beschrieben habt.
Es ist ein Monster Datenobjekt.

Ich hatte auch erst gedacht ein DataTransferObjekt zu bauen. Allerdings ist das wirklich unmöglich. Ich brauche nämlich so viel von dem Objekt, dass man dann direkt über ein neue (moderne) Architektur nachdenken sollte.
Der Aufwand wäre dann der gleiche.

Ich danke euch aber. Eure Gedanken werden mich dazu bringen nochmal grundsätzlich darüber nachzudenken (ggfs. auch mit dem Kunden).

Gute Nacht
Unfug

4.939 Beiträge seit 2008
vor 3 Jahren

Nur als Hinweis: ein Dictionary kann doch als JSON serialisiert werden, s. System.Text.Json can’t serialize Dictionary unless it has a string key (also entweder Newtonsoft.Json benutzen oder eigenen Converter schreiben).