0

質問: 開発者が独自のシリアライズ形式を作成することは、どのくらい一般的ですか? 具体的には、Javaを使用して、オブジェクトをトークン付きの巨大な文字列として送信し、変数を区切ります。

私の論理: 私はこれを選択しました。これは、言語の依存関係をほとんど排除する (Java の変更された UTF-8 を無視する) ためです。そのため、古いバージョンで実行されているクライアントはオブジェクト データを受信できません。コードはそれほど醜くなく、問題なく読めますが、私の質問は、このインスタンスのベストプラクティスは何ですか? これは個人的なプロジェクト用です。

その他の既知の選択肢: わかりました。オブジェクトをシリアル化してネットワーク経由で送信する作業をしていたところ、Google プロトコル バッファに遭遇しました。オブジェクトのシリアル化はどの程度標準化されていますか? 私は基本的にそれを行う3つの方法に出くわしました。（それが目的なので、ここでJavaについて話します）1）言語の（Javaの）ネイティブシリアライズクラスを使用します2）おそらく文字列とトークンを使用してオブジェクトをシリアライズする独自の方法を使用します3）プロトコルバッファを使用するまたはその他の既知の形式 (JSON、XML など)

私が収集したものから、シリアル化するときに達成する必要がある主な目標が基本的に 3 つあります。逆）

ほとんどの大規模なソフトウェア プロジェクトはプロトコル バッファを使用しますか? クライアントがリソースの少ないモバイル デバイスの場合、状況は変わりますか?

4

4 に答える 4

6

標準形式 (JSON、XML、さらには proto バッファー) を使用すると、統合ポイントを介してアプリを拡張する機会がはるかに多くなります。しかし、それが単なる内部的なものである場合は、簡単なことをしてください。個人的には、特定のオブジェクトのシリアル化された形式を表す専用の永続プロキシ クラスを作成します。次に、writeReplace と readResolve を使用して、最も理にかなった方法 (有線ライブ転送の Java シリアル化、長期永続化の xml) を使用してそのオブジェクトをシリアル化します。クラスが進化するにつれて、永続プロキシの完全に新しい実装を作成したり、プロキシにバージョン管理を追加したりできます...必要に応じて。このパターンについては、効果的な Java で Bloch が説明していると思います。

純粋にゼロからワイヤ プロトコルを考え出すことに関しては、アプリにとってパフォーマンスがどれほど重要であるかに大きく依存します。ほとんどの場合と同様に、標準ライブラリ/プロトコルを活用できるほど、新しいコードをより早く世に出すことができます。シリアル化などに関連するコードの巨大なチャンクを目にすると、私は通常、それをコードの匂いと見なし、それが正当化されたかどうかに細心の注意を払います。ちょうど私の 0.02 ドル。

PS - 誰かがグラフに関する質問を投稿しました...これは、実際には標準のシリアル化を意図的に避けた領域の 1 つです。複雑なグラフをシリアル化する Java の機能はあまり優れていません。グラフが少しでも複雑な場合でも、スタック オーバーフローの問題が発生します (笑)。このような場合、永続的なプロキシは非常に重要です。

于 2011-01-27T02:32:32.400 に答える
5

質問: 開発者が独自のシリアライズ形式を作成することは、どのくらい一般的ですか?

ゼロから作成することを意味すると仮定すると、答えは「かなり珍しい」です。

また、これを一般的に行うのは「ベストプラクティス」ではないと思います。ほとんどの場合、既存の一般的に使用されている代替手段 (Java シリアライゼーション、JSON、XML など) のいずれかが適切なソリューションを提供します。

IMO、明確な要件がある場合、または既存の代替手段が機能しないという明確な証拠がある場合にのみ、「独自の」形式を作成する (および対応するシリアル化/逆シリアル化コードを実装する) ことを検討する必要があります。「XYZ は遅い」という一般的な知恵は十分な証拠ではありません。

于 2011-01-27T03:41:33.843 に答える
2

すぐに頭に浮かぶいくつかのこと：

  • すべてのメッセージまたは接続ネゴシエーションにバージョン番号を含めます。それは大きな頭痛からあなたを救います。できれば、受信者がサポートしているバージョンを送信者に知らせてください。

  • 当然のことながらバイナリ データ (画像、音声) を送信する場合を除き、読み取り可能なプレーン テキスト (UTF-8) 形式を使用します。トラブルシューティングに大いに役立ちます。私は JSON に固執しますが、それはあなたにとって最適ではないかもしれません。XML には高いオーバーヘッドがあります。

  • メッセージが十分に長い場合は、gzip (GZIPOutputStream) などのよく知られたアルゴリズムで圧縮を試みることができます。

ご覧のとおり、これらの手順により、フォーマットのオープン性が促進され、サーバーと潜在的なクライアントの間の疎結合が促進されます。あなたのクライアントが将来どのような技術を使わなければならないかは誰にもわかりません。iPhone クライアントを作る気ですか? HTML5+JS クライアント? サーバーの同上:)

于 2011-01-27T02:39:48.793 に答える
0

構造化データの Xml の場合、JSON が最適な選択である可能性があります。ただし、単純なフラット レコードの場合は、CSV を検討することをお勧めします。実装がより簡単/高速であることに気付くかもしれません。非常に多数のレコードがある場合は、ウェルの管理が容易になる可能性があります。例: スプレッドシートにロードする

于 2011-01-27T07:01:03.383 に答える