Laden...

Wann sollte bei einer Socketverbindung die Response-Objekte instanziiert werden?

Erstellt von FUT320 vor 5 Jahren Letzter Beitrag vor 5 Jahren 877 Views
F
FUT320 Themenstarter:in
10 Beiträge seit 2018
vor 5 Jahren
Wann sollte bei einer Socketverbindung die Response-Objekte instanziiert werden?

Hallo zusammen,

ich habe eine grundlegende Frage.
Über eine Socket Verbindung werden mehrere XML-Dateien gesendet, auf welche jeweils eine andere Antwort folgen muss. Da die Inhalte der Dateien unterschiedlich sind, muss die Antwort immer individuell generiert werden. Für die Antworten habe ich jeweils eine Klasse angelegt, also zum Beispiel:

XML-Dateien:
XML1, XML2, XML3

Klassen:
ResponseXML1, ResponseXML2, ResponseXML3

Nun werden die Dateien gesendet und ich prüfe welche ankam bzw. welche Antwort notwendig ist. Wann ist es aber nun am sinnvollsten die Objekte der Klasse zu erzeugen.

Sollte ich bereits beim Aufbau der Verbindung
ResponseXML1 resXML = new ResponseXML1 schreiben und alle XML1 mit diesem Objekt bearbeiten oder sollte mit jeder XML ein neues Antwort Objekt erzeugt werden?

Dass beide Varianten funktionieren, ist mir durchaus bewusst. Mir geht es nun eher darum zu verstehen, warum die Variante besser ist als die andere oder ob es noch eine dritte Möglichkeit gibt.

Vielen Dank im Voraus.

P
1.090 Beiträge seit 2011
vor 5 Jahren

Hi Fut320,

eine pauschale Antwort gibt es nicht darauf.

Grundlegend ist es wichtig, das der Code gut verständlich ist. Meist ist es dabei Sinnvoll die Objekte da zu erzeugen, wo sie auch gebraucht werden.

Ein anderer Punkt ist die Erweiterbarkeit. Da kann Dependency Injection mit einem IoC Container sehr nützlich sein. Statt also deine Klasse für die Antwort direkt zu erzeugen, könntest du eine IList<IAntwort> rein geben. Die dann z.B. die Methoden IsAntwort und GetAntwort haben. Da kannst du in einer Schleife drüber laufen und feststellen welche Antwort gesendet werden kann und die dann senden. Dann brauchst du immer nur eine passende Klasse anlegen. (Wenn du grade Programmieren lernst ist das vielleicht ein bisschen komplex).

Was wichtig ist kümmer dich erst mal nicht so um Performance und Speicherverbrauch. Sondern schau das du Code schreibst der gut verständlich ist. Und Wartbar.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

T
2.219 Beiträge seit 2008
vor 5 Jahren

Palin gibt hier schon ein paar gute Tipps.
Ich würde aber jede Anfrage mit einem eigenen Response Objekt beantworten.
Das schlimmste was du machen kannst ist eine Instanz über alle Anfrage teilen.
Da dein Response Objekt ggf. auch eine internen Zustand haben kann, der je nach Anfrage unterschiedlich sein kann wäre es fatal wenn durch mehrfache gleichzeitige Anfragen ein falscher interner Zustand erzeugen und deine Antworten an eine Anfrage die Antwort für eine andere Anfrage schickt.

Zwar wäre der Ansatz mit einem Objekt auf der Serverseite dann je nach Menge der gleichzeitigen Anfragen Speicherschonender, müsste aber eben mit zusätzlichem Aufwand in der Programmierung und ggf. durch Locks bei geteilten Resourcen abgedichtet werden.

Ich bevorzuge bei solchen Szenarien erst einmal einen "Shared Nothing" Ansatz.
Somit sollte jede Anfrage ihre eigenen Resourcen und Objekte verwenden um nicht durch Locks o.ä. die Performance zu blocken oder gar Fehler durch gleichzeitige Zugriffe zu verursachen.
Nur wenn es wirklich nötig wäre, eben durch zu hohen Speicherverbrauch oder zu viele tote Objekte, die einen hohen GC Aufwand fordern, würde ich über geteilte Resourcen nachdenken.

Am besten wäre es also, wie auch schon Palin schreibt, sich erst einmal auf die eigentliche Umsetzung zu konzentrieren.
Neben sauberen und wartbaren Code sollte man auch erst einmal funktionierenden Code schreiben.
Wenn der Code nicht funktioniert sind auch alle voreiligen Optimierungen ein unnötiger Mehraufwand der nicht mal gerechtfertigt ist.

Zum Teil geht dieser Denkansatz auch schon wieder in Richtung zu früher Optimierung.
Erst wenn du ein konkretes Problem siehst, eben hoher Speicherverbrauch oder häufige GCs solltest du dir um solch einen Ansatz sorgen machen.

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.

F
FUT320 Themenstarter:in
10 Beiträge seit 2018
vor 5 Jahren

Guten Morgen,

danke für eure hilfreichen Antworten!