1

スプリングレストコントローラーメソッドでjsonに変換される次のJava JPAオブジェクトがあります。 

class User{
    @JsonManagedReference
    @OneToMany
    private Portfolio portfolio;
    .....
}

class Portfolio {
     @JsonBackReference
     @ManyToOne
 private User user;

    @JsonManagedReference
     private List<Order> orders;
     .....
}

class Order {
     @JsonBackReference
 private Portfolio portfolio;

     private User user;
}

私のアプリケーションでは、2 つのサービスが必要です。

  1. Logon: Portfolio オブジェクトと List of Orders オブジェクトを含む User オブジェクトを返します。これには Order.user オブジェクトは必要ありません。

  2. GetOrders: 注文のリストを返します。これには Order.user オブジェクトが必要です。

Order.user は、親の User オブジェクトと同じではありません。

私の質問は、User オブジェクトの無限再帰の問題を回避する方法です。それとも、これは単に設計が悪いのでしょうか?

4

1 に答える 1

2

@JsonManagedReferenceとの問題@JsonBackReferenceは、非常に特殊な種類の (直接の) 循環参照を適切に処理するが、その狭いウィンドウ (単一の親オブジェクトが 1 つ以上の子オブジェクトに直接関連している場合) の外で何かを処理するように設計されていないことです。残念ながら、あなたのユースケースはその枠には収まりません。

したがって、次の 2 つのオプションがあります。

  • order.user手動による回避策 - サービス クラスでは、最上位userオブジェクトをシリアル化する前に、プロパティを削除 (null にする) する必要があります。user.portfolio.orders逆に、をシリアル化する前に、プロパティを削除 (null にする) する必要がありますorders。

  • フレームワークの回避策 - Jackson 2.0+ にアップグレードして使用します@JsonIdentityInfo。グラフ、多対多の関係、深いオブジェクト ツリーなどのオブジェクト参照を適切に処理できます。いくつかのドキュメントと例。

を制御できる場合は、問題を回避することもできますObjectMapper。その場合、返すオブジェクトに応じて使用するカスタムシリアライザーを指定するだけで済みますが、Spring フレームワーク内で作業しているため、マッパーを直接制御できるとは思えません。

私の個人的な推奨事項は、Jackson ライブラリをアップグレードして使用すること@JsonIdentityInfoです。

于 2013-01-12T13:56:02.567 に答える