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 item = 1;
}
message CustomerInvoice {
required ShippingAddress address = 1;
required ItemList = 2;
required double amountPayable = 3;
}
このようなメッセージの代わりに：
message CustomerInvoice {
required ShippingAddress address = 1;
repeated Item item = 2;
required double amountPayable = 3;
}
私は後者が好きですが、それに対する議論を聞いてうれしいです。