タグ付けされた質問 「protobuf」

JavaベースのサービスのGoogleプロトコルバッファーを評価しています（ただし、言語に依存しないパターンを期待しています）。2つの質問があります。 1つ目は、広く一般的な質問です。 人々が使用するパターンは何ですか？上記のパターンは、クラス編成（たとえば、.protoファイルごとのメッセージ、パッケージ化、および配布）およびメッセージ定義（たとえば、繰り返しフィールドと繰り返しカプセル化されたフィールド*）などに関連しています。 Google Protobufのヘルプページや公開ブログにはこの種の情報はほとんどありませんが、XMLなどの確立されたプロトコルに関する情報は大量にあります。 また、次の2つの異なるパターンに関する具体的な質問もあります。 .protoファイルでメッセージを表し、それらを個別のjarとしてパッケージ化し、サービスの消費者をターゲットに出荷します。これは基本的にはデフォルトのアプローチです。 同じことを行いますが、少なくともこれらの2つのメソッドをサポートするコントラクトを実装する各メッセージの周囲に、手作りのラッパー（サブクラスではありません！） ： public V toProtobufMessage() { V.Builder builder = V.newBuilder(); for (Item item : getItemList()) { builder.addItem(item); } return builder.setAmountPayable(getAmountPayable()). setShippingAddress(getShippingAddress()). build(); } public static T fromProtobufMessage(V message_) { return new T(message_.getShippingAddress(), message_.getItemList(), message_.getAmountPayable()); } 私はによって導入複雑さを離れて非表示にすることができますことを、私は（2）を参照の1つの利点はV.newBuilder().addField().build()、そのようにいくつかの意味のあるメソッドを追加しisOpenForTrade()たりisAddressInFreeDeliveryZone()など、私のラッパーに。（2）で見た2番目の利点は、クライアントが不変オブジェクト（ラッパークラスで強制できるもの）を処理することです。 （2）の欠点の1つは、コードを複製し、ラッパークラスを.protoファイルと同期する必要があることです。 誰かが2つのアプローチのいずれかについてより良い技術やさらなる批判を持っていますか？ *繰り返しフィールドをカプセル化するということは、次のようなメッセージを意味します。 message ItemList { repeated …

19 serialization  protobuf 

protobufの構文3は、すべてのフィールドをオプションにし、キーワードrequiredを削除し、optional以前のproto2構文から削除しました。開発者からのコメントを読むと、前方/後方バイナリ互換性を強化するために行われたようです。 しかし、私にとっては、パッケージ名をバージョン管理するだけで強制できます。たとえばcom.example.messages.v1、クライアントが理解できるデシリアライザーを実装できるようにします。同時に、ソフトウェアエンジニアリングの観点から有用なタイプとして指定されている一部の契約を削除します。たとえば、私が持っている場合 message Location { double latitude = 1; double longitude = 2; } proto3ではLocation、必須フィールドの1つを提供しないことにより、完全に有効な半バックアップを作成できます。 クライアント間でデータを交換するためのスキーマベースのシリアル化形式を作成する場合、これは大きな欠点ではありませんか？すべての必須フィールドに有効な値があることを確認するために、各クライアントに追加の検証コードを移動するのは悪くありませんか？

15 event-programming  event-sourcing  protobuf