Webサービスへの入力と出力の両方として使用されるJibx Beanがあります。豆は非常に大きく複雑で、親子関係が深い。 Webサービスは要求オブジェクトを返しませんが、一部のプロパティが設定された新しいBeanを返します。私は私の要求と応答を結合したいと思います。私はDozerを使ってみました（私のリクエストオブジェクトをレスポンスに置き換えた、つまり、元のリクエストプロパティは失われてしまいました！）Beit for BeanUtils.copyProperties）。オブジェクトグラフが大きすぎると、すべてのプロパティでisNullチェックができません。JavaでのBeanのマージ
私は、BeanをXMLに変換し、EL4J XML Merge を使用してそれらをマージすることを検討しました。
"isNullチェックを行うには大きすぎると深すぎます"私はこれらのチェックをハードコードしたくないと仮定しています。あなたもそうではありません。
しかし、豆についての美しい点は、検査が可能であることです。また、オブジェクトグラフを使って作業し、ヌルをチェックし、そうでなければ更新する自動チェックを書くことができます。
はい、それはCPUを大量に消費します。しかし、確かに、XMLを生成し、それをマージしようとする以上のCPUを必要としません。
オブジェクトがBeanであるため、なぜBeanを要求に関連付けるのではなく、返信するときに要求Beanを使用するのですか？私は、インタフェースオブジェクトだけのオブジェクトをシステムに押し込むことを主張しているわけではありませんが、リクエストBeanを保持してレスポンスBeanにしています。
深度引数についてもわかりませんが、入力レイアウトによって応答を生成するロジックが複雑な場合は、プロパティが計算される前にレスポンスポピュレーションコードを構築することをお勧めします。システムは、どのプロパティーを計算するかを決定して、これらのプロパティーを応答Beanに戻す戦略を構築することもできます。これは戦略パターンと同じくらい簡単かもしれませんが、より複雑な状況では、バイトコードの変更ライブラリを検討するかもしれません。
もう1つのアプローチは、XMLのプロパティが似ており、「深み」が取り除かれるようにインターフェイスを単純化することです。すべてのプロパティを同様にすると、単純なループでプロパティのチェックと集計を管理できます。
XMLに変換すると、最初にフレームワークを使用してオブジェクトが幾分か無効になります。おそらく、XMLが簡単な場合、Jibxは問題の最も簡単な解決策ではありません。あなたの仕様で何が変わることができますか？