1

私が取り組んでいるこのRESTfulAPIの基礎となるPOJOがいくつかあります。ただし、APIをより完全にするために、他の情報を含める必要がある応答もあります。これらの追加情報をPOJOに入れたくはありませんが、あたかもそうであるかのようにWebサービスレイヤーに含めます。

それは「予定」を持っている「人々」を扱います。各予定には1人しかいません。

したがって、/ Patients / 1のようなRESTful呼び出しがあり、基本的にPersonのPOJOを取得し、現在XStreamを使用してシリアル化して送信しています。これはうまく機能しますが、私は次のようなことをしたいと思います。

<Person> 
<firstName>James</firstName>
 ... other fields ...
<nextAppointment href="/Appointment/12345>2010-02-19</nextAppointment>
<prevAppointment href="/Appointment/12346>2010-01-01</prevAppointemnt>
</Person>

次および前の予定が実際にPersonPOJOに含まれていない場合。私はこれを達成するための良い「春の方法」を探しています。クライアントはこの/Patients/ 1/PreviousAppointmentや/Patients/ 1 / NextAppointmentのようなことをすることができますが、私は呼び出しの量を減らし（おそらく事前最適化？）、必要に応じてより多くの情報を取得する方法を提供したいと考えています彼のhrefを使用してそれを。

XStreamMarshallerを使用すると、POJOまたはPOJOのリストのビューを処理するだけなので、非常にエレガントです。しかし、私はそれらが送られる前にそれらを少し医者にする必要があります。

ありがとう！

4

2 に答える 2

1

これは、ビジネスオブジェクトをマーシャラーに直接渡す際の問題です。オブジェクトを応答に変換する方法にはほとんど柔軟性がありません。オブジェクトを自分で事前変換するために言わなければならないことがあります。そうすることで、より多くの制御を得ることができます。

したがって、必要な特定の出力構造がある場合は、XStreamを使用して、それに似たクラス構造を構築する必要があります。次に、ビジネスオブジェクトをそのクラス構造に変換し、代わりにそれをXStreamに渡します。

あまりエレガントに見えないかもしれませんが、現在のXStreamベースのシステムと同じように、ビジネスオブジェクトモデルの小さな変更によってシステムが破損する可能性ははるかに低くなります。

于 2010-01-10T10:46:50.553 に答える
1

問題の解決策：カスタマイズされたコンバーターを作成します...

パブリッククラスCustomizedConverterはConverter{を実装します

@Override public void marshal（Object source、HierarchicalStreamWriter writer、MarshallingContext context）{....}

@Override public Object unmarshal（HierarchicalStreamReader reader、UnmarshallingContext context）{..}

@Override public boolean canConvert（Class clazz）{..}

}

マーシャラーでコンバーターを使用する方法を知るには、これを参照してください。

したがって、基本的にCONVERTERはPOJOで動作し、コントラクトで指定されたXML応答を確実に取得します。

于 2010-05-24T15:41:30.237 に答える