0

いくつかのモデル オブジェクトのログに NotSerializableException が表示されています。これを修正するには、それらをシリアル化できるようにする必要があることはわかっていますが、コンポーネントがページに追加されていないという MarkupExceptions も表示されています。これは関連している可能性があります。クラスタリングがオンになっている本番環境でのみエラーが表示されます。

私の質問は、すべての属性がシリアライズ可能であっても、モデルオブジェクトがシリアライズ可能でない場合はどうなりますか?

4

1 に答える 1

1

私の知る限り、クラスをシリアライズ可能として宣言しないと、後続のアクション (フォーム送信、動作、AJAX など) でシリアライズされたバージョンから欠落します。したがって、オブジェクトが逆シリアル化されると、子オブジェクトをストレージから正常に再ロードできない場合、オブジェクト参照が null になる可能性があります。

オブジェクトを不必要にシリアライズすることは絶対に避けてください。これには、AJAX 要求への応答が含まれます。

ベスト プラクティスは次のとおりです。

  1. 必要最小限のシリアル化されたオブジェクトのみを保存する

    • 変数を「final」と宣言し、匿名の内部クラスからこれらを参照することは避けてください
    • シリアル化されたオブジェクト (ページ、パネル、リストなど) にフィールドとして保存されるオブジェクトが多すぎないようにする

  2. リクエストごとにオブジェクトをロードします。特にモデル オブジェクトは、リクエストが処理されるたびにデータ リポジトリからロードする必要があります。

  3. コンストラクターの外部でデータ オブジェクトをロードする

  4. すべてのデータにモデルを使用し、単純化のために Wicket 構造をミラーリングしようとします (たとえば、使用される wicket:id に基づいて、リフレクションを使用してモデル オブジェクトからフィールドがロードされる CompoundPropertyModel を使用します)。

  5. ロードされる大きなオブジェクトには取り外し可能なモデルを使用してください

  6. 匿名の内部クラスを使いすぎないようにします。適切なイベント ハンドラーを使用して、コードが読みやすく、保守しやすいようにします。

私は複雑な Wicket アプリケーションにしばらく取り組んできましたが、シリアライゼーション/デシリアライゼーションの使いすぎによるオブジェクトの重複は避けたいと思います。デバッグと修正は悪夢になる可能性があります。

詳細/提案については、これらをお読みください。

http://letsgetdugg.com/2009/04/19/wicket-anti-patterns-avoiding-session-bloat/ https://cwiki.apache.org/confluence/display/WICKET/Best+Practices+and+Gotchas

于 2013-11-11T11:42:54.390 に答える