Wersja Jona jest w dużej mierze portem w wersji Java, więc ma bardzo podobne API i podejście do projektowania. Jest to także AFAIK całkowicie kontraktowo-pierwszy, tj. Z .proto.
Moja wersja jest bardziej dostępna w perspektywie .NET, patrząc na to, co jest typowe w serializerach .NET - więc obiekty zmienne, doposażenia w istniejące typy, najpierw w kodzie (chociaż może nadal robić kod-gen z a .proto, jeśli chcesz), itp. Może nawet wnioskować dane z atrybutów używanych przez XmlSerializer i DataContractSerializer do pracy obok istniejącego kodu i może być podłączone do obu zdalnych (przez ISerializable) i WCF (poprzez atrybuty lub konfiguracja). Jest więc głęboko zakorzeniony w ekosystemie .NET. Mam również obsługę dziedziczenia (ponieważ jest to tak powszechne w innych serializatorach .NET), ale jest to trochę skomplikowane, aby mapować na inne platformy, ponieważ nie ma bezpośredniej reprezentacji w .proto.
Dane binarne powinny być identyczne; to w dużej mierze kwestia formatu; p Jest to w dużej mierze wybór, który interfejs API może być bardziej odpowiedni dla ciebie.
Dla twoich potrzeb, pracując równolegle z C++ i kodem Java w tym samym systemie iz istniejącymi definicjami .proto, proponuję wersję Jona może być najbardziej odpowiednią opcją dla ciebie.
Jeśli jednak robisz .NET tylko, albo robią z .NET współdziałanie z zewnętrznego kodu (czyli nie obchodzi co język „po drugiej stronie” używa, ponieważ trzeba tylko martwić się o własny kod), a następnie protokół IMO protobuf-net może być dość bezbolesnym sposobem konsumowania danych; , szczególnie, jeśli masz istniejący system, który teraz chcesz przekształcić do postaci szeregowej (lub: serializować szybciej/mniej).
Dzięki Marc. Użyliśmy twojej wersji od pierwszego dnia, ale szukałem pewnych wyjaśnień, zwłaszcza, że coraz więcej zespołów zaczyna korzystać z bibliotek. –
@Ray następnie używaj go i ciesz się; –