3

現在、Web サービスの入力/出力を XML でエンコードするために XStream を使用しています。ただし、複数の言語 (protobuf、Thrift、Hessian など) 用のコード ジェネレーターを使用してバイナリ形式に切り替えることを検討しています。これにより、新しいクライアントのサポートがより簡単になり、ハンド コーディングへの依存度が低くなります (また、バイナリ データを含むメッセージ形式をより適切にサポートするため)。 .

ただし、サーバー上のオブジェクトのほとんどは、XStream がリフレクションと注釈を介してシリアル化を処理する POJO であり、これらのライブラリのほとんどは、POJO 自体を生成すると想定しています。代替ライブラリに接続する方法はいくつか考えられます。

  1. ターゲット形式の XStream マーシャラーを記述します。

  2. 代替ライブラリによって生成されたクラスとの間で POJO をマーシャリングするカスタム コードを記述します。

  3. 生成されたクラスをサブクラス化して、POJO ロジックを実装します。書き直しが必要な場合があります。(また、テラコッタを使いたいと言いましたか?)

  4. リフレクション (XStream など) とコード生成の両方をサポートする別のライブラリを使用します。

ただし、どのシリアライゼーション ライブラリが上記の手法に最適かはわかりません。

4

1 に答える 1

1

(1)多くのシリアライゼーション ライブラリには、プリミティブ値と区切り記号の読み取り/書き込み方法を認識しているヘルパー API が含まれているため、それほど多くの作業ではない可能性があります。

(2) おそらく最も幅広いツールの選択肢が得られます: https://github.com/eishay/jvm-serializers/wiki/ToolBehavior (言語に依存しないものもあります)。欠陥がありますが、完全に役に立たないベンチマークではないことを願っています: https://github.com/eishay/jvm-serializers/wiki

これらのツールの多くは、POJO との間で変換するコードを記述する必要があるクラスを生成します。通常、POJO を直接操作するツールは言語に依存しません。

（3）は悪い考えのようです（特定のプロジェクトについて何も知らない）。私は通常、メッセージ クラスを他のロジックから解放します。

(4) Protostuff ライブラリ(プロトコル バッファ形式をサポート) を使用すると、POJO をシリアル化する方法を記述する「スキーマ」を記述できます。しかし、このスキーマを作成することは、POJO と一部のツールの生成されたクラスとの間で変換するコードを作成することよりも、より多くの作業とエラーが発生しやすくなる可能性があります。

Protostuff はリフレクションを介してスキーマを自動的に生成することもできますが、これにより、Java 中心のメッセージ形式が生成される可能性があります。

于 2011-04-03T20:23:31.880 に答える