34

Protocol Buffer for .NET は Remoting (SerializationFormat.Binary) より軽量/高速になりますか? 言語/フレームワークの観点から、それに対するファーストクラスのサポートはありますか? つまり、Remoting/WebServices のように透過的に処理されますか?

4

2 に答える 2

37

このページには、いくつかのパフォーマンスとサイズの指標があります。ページが少し古いため、現時点では Jon の統計情報はありません (Jon: 修正する必要があります!)。

透明であること。protobuf-netは、コントラクトを介して WCF にフックできます。basic-http を介した MTOM でもうまく機能することに注意してください。ただし、Silverlight には注入ポイントがないため、これは Silverlight では機能しません。svcutil を使用する場合は、(部分クラスを介して) クラスに属性を追加する必要もあります。

Re BinaryFormatter (リモーティング); はい、これは完全にサポートされています。これは簡単な実装で簡単に実行できます(つまり、同じ引数でメソッドをISerializable呼び出すだけです)。Serializerを使用protogenしてクラスを作成する場合は、コマンド ラインで引数を使用して有効にできます (BinaryFormatterすべてのフレームワーク [CF など] では機能しないため、デフォルトでは有効になっていません)。

ローカル リモーティング (IPC) の非常に小さなオブジェクト (単一インスタンスなど) の場合、生のBinaryFormatterパフォーマンスは実際には優れていることに注意してください。

また、プロトコル バッファ ワイヤ形式は継承を直接サポートしていないことにも注意してください。protobuf-net はこれをスプーフィングできますが (ワイヤー互換性を維持しながら)、XmlSerializer と同様に、事前にサブクラスを宣言する必要があります。

なぜ 2 つのバージョンがあるのですか?

オープンソースの楽しさ、私は推測します;-p Jon と私は以前に共同プロジェクトに取り組み、これら 2 つをマージすることについて話し合ったことがありますが、実際には、それらは 2 つの異なるシナリオを対象としています。

  • dotnet-protobufs (Jon の) は、既存の Java バージョンのポートです。これは、すでに Java バージョンを使用しているすべての人にとって非常に使い慣れた API を備えていることを意味し、典型的な Java コンストラクト (ビルダー クラス、不変データ クラスなど) にいくつかの C# ひねりを加えて構築されています。
  • protobuf-net (Marc's) は、同じバイナリ形式 (実際、重要な要件は、異なる形式間でデータを交換できることです) に従うゼロからの再実装ですが、典​​型的な .NET イディオムを使用しています。
    • 変更可能なデータ クラス (ビルダーなし)
    • XmlSerializerシリアライゼーション メンバーの詳細は、属性で表現されます ( 、などと同等DataContractSerializer)。

Java および .NET クライアントで作業している場合、両方の側で使い慣れた API を使用するには、Jon のものがおそらく適切な選択です。純粋な .NET を使用している場合、protobuf-net には利点があります。使い慣れた .NET スタイルの API だけでなく、次の利点もあります。

  • コントラクト優先である必要はありません(可能ですが、コード ジェネレーターが提供されています)。
  • 既存のオブジェクトを再利用できます (実際、多くの場合[DataContract]、[XmlType]クラスはまったく変更せずに使用できます)
  • 継承を完全にサポートしています (これは、カプセル化をスプーフィングすることによってネットワーク上で達成されます) (プロトコル バッファーの実装に固有の可能性があります? サブクラスは事前に宣言する必要があることに注意してください)。
  • コア .NET ツール ( BinaryFormatter、XmlSerializer、WCF などDataContractSerializer) にプラグインして活用することで、リモート エンジンとして直接動作できるようになります。これはおそらく、Jon の移植用のメインの Java トランクからかなり大きな分割になるでしょう。

それらを再マージします。私たちはどちらもそれを受け入れると思いますが、両方の機能セットが必要になる可能性は低いと思われます。

于 2009-01-24T11:42:53.270 に答える
37

言語の直接サポートやフレームワークのサポートさえも提供されるとは思えません。これは、サードパーティのライブラリで完全にうまく処理されるようなものです。

私自身の Java コードのポートは明示的です。シリアライズ/デシリアライズするには、メソッドを呼び出す必要があります。(自動的にシリアライズ/デシリアライズする RPC スタブがありますが、RPC 実装はまだありません。)

ただし、 Marc Gravell のプロジェクトは WCF と非常にうまく適合しています。私の知る限り、シリアル化にプロトコル バッファを使用するように (1 回) 指示するだけで、残りは透過的です。

速度に関しては、Marc Gravell のベンチマーク ページを参照してください。私のコードは彼のコードよりもわずかに高速になる傾向がありますが、どちらもフレームワークの他のシリアライゼーション/デシリアライゼーション オプションよりもはるかに高速です。プロトコル バッファも同様にはるかに制限されていることに注意してください。任意の型をシリアル化しようとせず、サポートされているものだけをシリアル化しようとします。将来的には、(独自のプロトコル バッファ メッセージとして) 移植可能な方法で、より多くの一般的なデータ型 (10 進数、DateTime など) をサポートする予定です。

于 2009-01-24T10:10:13.830 に答える