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:
Das Datenobjekt in JSON umwandeln, um es über REST zu senden
Fehlgeschlagen, da interne Propertys wie Dictionarys nicht in JSON umgewandelt werden können.
Das Datenobjekt mittels BinaryFormatter serialiseren, um es als STREAM zu senden
Fehlgeschlagen, da nicht alles als serializeable markiert.
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
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.
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.
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
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).