Protokollpuffer und OO-Design

8

Ich bin mit Protokollpuffer als Draht Daten-Format in einer Client-Server-Architektur. Domain-Objekte (Java-Beans) durchlaufen den folgenden Lebenszyklus.

  1. Wird in der clientseitigen Geschäftslogik verwendet
  2. In das protobuf-Format konvertiert
  3. Übertragen auf den Server
  4. Zurück in Domänenobjekt
    5. konvertiert
  5. Wird in der serverseitigen Geschäftslogik verwendet

"Protocol Buffers und OO Design" Abschnitt in protobuf Dokumentation empfiehlt Verpackung erzeugte Klasse in der richtigen Domain-Modell .

Ich möchte die beste appoach finden-out.

Für z.B. Ich habe eine einfache Proto-Definition.

%Vor%

So ist das Domänenmodell definiert. Wie Sie sehen können, werden die Daten vollständig in proto-Builder-Objekt gespeichert.

%Vor%

Ist das eine gute Übung? werden, weil diese Objekte in allen Phasen des Lebenszyklus verwendet, aber wir müssen nur protocolbuf Format bei Übertragungsphase Client-Server.

Gibt es ein Performance-Problem, wenn Proto-Builder-Klasse Getter / Setter-Methoden Zugriff auf speziell wenn Proto Definition komplex und verschachtelt ist?

    
Sujee 02.08.2012, 08:19
quelle

2 Antworten

5

Ich habe keine Erfahrung mit Protokollpuffern, aber ich würde nicht die Implementierung Ihrer Domänenobjekte empfehlen, die auf ein bestimmtes Serialisierungs- / Übertragungsframework zugeschnitten sind. Sie könnten das in der Zukunft bereuen.

Die Domänenobjekte und die Logik einer Softwareanwendung sollten von bestimmten Implementierungsproblemen (in Ihrem Fall Serialisierung / Übertragung) so unabhängig wie möglich sein, weil Ihre Domäne in Zukunft einfach zu verstehen und wiederverwendbar / wartbar sein soll.

Wenn Sie Ihre Domänenobjekte unabhängig von Serialisierung / Übertragung definieren wollen, haben Sie zwei Möglichkeiten:

  1. Vor der Serialisierung / Übertragung kopieren Sie die Informationen in das Protokoll Puffert bestimmte Objekte und sendet sie an Ihren Server. Da du müsste die Informationen zurück in Ihre Domain-Objekte kopieren.
  2. Verwenden Sie eine Nicht-Protokoll-Serialisierungsbibliothek wie Kryo oder ProtoStuff , um Ihre Domain-Objekte direkt in die Server.

Die Nachteile von Option 1 sind, dass Ihre Domäne zweimal definiert ist (was in Bezug auf Änderungen unerwünscht ist) und das Kopieren von Informationen (was fehleranfälligen und nicht wartbaren Code erzeugt).

Die Nachteile von Option 2 sind, dass Sie verlieren Schema-Evolution (obwohl ProtoStuff anscheinend dies unterstützt ) und das vollständige (möglicherweise große) Objektdiagramm wird serialisiert und übertragen. Obwohl Sie das Objektdiagramm (manuell oder mit JGT ) vor der Serialisierung / Übertragung beschneiden können.

    
Barry NL 03.05.2013, 13:51
quelle
2

Wir haben einen Protobuf-Converter erstellt, um das Problem der Transformation Ihrer Domain-Modell-Objekte in Google Protobuf-Nachrichten zu lösen und umgekehrt.

So verwenden Sie es:

Domänenmodellklassen, die in protobuf-Nachrichten umgewandelt werden müssen, müssen Bedingungen erfüllen:

  • Die Klasse muss durch @ProtoClass Annotation gekennzeichnet sein, die enthält Verweis auf verwandte Protobuf-Nachrichtenklasse.
  • Klassenfelder müssen mit @ProtoField Annotation markiert sein. Diese Felder müssen Getter und Setter haben.

ZB:

%Vor%

Code für die Konvertierung der Benutzerinstanz in eine verwandte Protobuf-Nachricht:

%Vor%

Code für die Rückwärtskonvertierung:

%Vor%

Die Konvertierung von Listen von Objekten ähnelt der Konvertierung einzelner Objekte.

    
Roman Gushel 11.05.2016 09:29
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Warum ist das Ausrichten von langen long union member größer als die beinhaltende union / struct? Ist das richtig?