簡単な注文照会V 1:ダイレクト露出エンティティ

今日は最も重要な部分を完璧に理解します!ペン。

無限ループメンバーにはOrdersがあり、Ordersメンバーには
双方向関連では、JsonIgnoresが必要です.



Deliver , Member , OrderItem
これも間違いです.

Order.Classは遅延ロードがあります...
プロキシメンバーの作成と配置

メンバーオブジェクトに接触したときにメンバーオブジェクトを取得する(プロキシ初期化)
だから問題はどうやって解決しますか?
遅延ロードの場合->これはヘブネット、ジェイソンライブラリ、何もしないでください...
->HyperNavight Findモジュールのインストール

implementation group: 'com.fasterxml.jackson.datatype', name: 'jackson-datatype-hibernate5'

インストールしましょう.バージョン情報を書かなくても、最適なバージョンをダウンロードできます.


nullは遅延ロードデバイスでクエリーされません.
このように解決するには...(でも重要じゃない…)

オプションを追加すると、遅延ロードも呼び出されます.

シンボルを使用してspecを変更...大変なことになった...(エクストラ露出)
パフォーマンスの問題.(無効にしても呼び出されます...)

整理する

Lazy Lodingが上にオプションを書いているので...だめだと言います.
私たちは最初からエンティティを使用しないでください.

オプションを使わなければ、李ギョンウを使っても正常に出力できます.
しかし出力形式は複雑です...
データが露出してしまうと、運営が難しくなります.
できるだけ必要なデータだけを暴露します.
Dtoに戻る

V2

しかしlazyロードによる...データベース・クエリーが呼び出されすぎます.
上の結果は3つのテーブルをクエリーします.


ORDER->SQL 1番->結果オーダー数2個.
1サイクル目->受注のメンバー納入を最初の受注で問い合わせる
2回目のループ->2回目のオーダーでメンバーを問い合わせる
クエリー...5回...order 1 Member 2 Delivery 2
N+1の問題.1+Nの問題に考えてもいいですか?
N+1->1+会員N+出荷N

パッチチェックイン最適化V 3

ペチジョーンとして、一度に持って帰りましょう.

欠点は?コラムが多すぎる...

ダイレクトクエリDTO

v 3と比較すると...v 4は再利用性がない.確かにきれいになりました...
v 4はパフォーマンスの最適化に役立ちます
v 4はスクリーンに依存...画面を変えたら全部分解して修理します...
最近は性能がよく、両者の間に性能の違いはありません.(Joinは性能が悪い)
v 4の場合、パフォーマンスを最適化するためにRepositoyパッケージにパッケージを個別に作成します.

このように...