14

プロジェクト内で gRPC と protobuf を使用するための「ベスト プラクティス」をオンラインで見つけることができませんでした。イベントソースのサーバー側アプリを実装しています。コアは、外部に依存することなく、ドメインの集約、イベント、およびサービスを定義します。gRPC サーバーは、要求オブジェクトを渡すコア サービスを呼び出します。これは、最終的に発行されるイベントに変換されます。イベントは、protobuf を使用してシリアル化され、ネットワーク上で公開されます。現在、イベントを直接 protobuf 生成クラスにするか、コアとイベントを分離してマッパー/シリアライザー レイヤーを実装し、protobuf <-> コア間でイベントを変換するかについて、ジレンマに陥っています。

検討していない別のアプローチがある場合は、ご案内ください:)

助けてくれてありがとう。

4

2 に答える 2

1

Protobuf はシリアライゼーションと下位互換性には非常に優れていますが、ファースト クラスの Java オブジェクトであるという点ではあまり優れていません。プロトにカスタム機能を追加することは現在できません。スタブ レイヤーで Protobufs を使用し、それらをイベント Pojo の 1 つにラップし、内部で次のように渡すことで、多くの利点を得ることができます。

public final class Event {
 private final EventProto proto;

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

ほとんどのプロジェクトは、.proto ファイルをそれほど頻繁に変更することはなく、下位互換性のない方法 (ワイヤーでも API でもありません) で変更することはほとんどありません。プロトの変更のために多くのコードを変更しなければならないことは、私の経験では決して問題ではありませんでした。

于 2016-04-19T15:09:49.810 に答える