Korzystanie z klas Protobuf w porównaniu z ramą/warstwą odwzorowania w języku Java

Question

Nie można znaleźć żadnych "najlepszych praktyk" w Internecie do korzystania z gRPC i protobuf w ramach projektu. Wdrażam aplikację poboczną od strony serwera. Rdzeń definiuje agregaty domen, zdarzenia i usługi bez zewnętrznych zależności. Serwer gRPC wywołuje podstawowe usługi przechodzące w obiektach żądania, co ostatecznie przekłada się na publikowane zdarzenia. Zdarzenia są serializowane za pomocą protokołu protobuf i publikowane na drucie. Jesteśmy obecnie przed dylematem, czy na nasze imprezy powinny być protobuf generowane klas bezpośrednio, czy też powinniśmy zachować rdzeń i zdarzenia oddzielić i wdrożenie warstwy mapper/serializer tłumaczyć wydarzenia między Protobuf < -> Rdzeń

Jeśli jest inne podejście, którego nie rozważamy, proszę, poprowadź nas :)

Dzięki za pomoc.

Answer 1

Protobufs są naprawdę dobre do serializacji i kompatybilności wstecznej, ale nie są tak dobre w byciu pierwszymi obiektami Java. Dodanie niestandardowej funkcjonalności do protosów nie jest obecnie możliwe. Można uzyskać wiele korzyści za pomocą Protobufs w warstwie skrótowej, zawinąć je w jednym z Twojego wydarzenia POJOs, i przekazać je wokół wewnętrznie jako takie:

public final class Event { 
private final EventProto proto; 

public void foo() { 
    // do something with proto. 
} 
} 

Większość projektów nie zmieniają pliku .proto często i prawie nigdy w sposób niekompatybilny wstecz (ani drut, ani API). Konieczność zmiany wielu kodów z powodu zmian proto nigdy nie była problemem z mojego doświadczenia.

Answer 2

Domain model Przedmioty i obiektów transferu danych (wiadomości) Protobuf należy oddzielić jak najwięcej. W tym celu najlepiej przekształcić Twoje Obiekty Modelu Domeny w Wiadomości Google Protobuf i odwrotnie. Zrobiliśmy protobuf-converter, aby uczynić go niezwykle prostym.