JPA/hibernate Spring framework

N+1問題でJPAを諦めるのはもったいない

投稿日:

JPAを実案件で使ってみて。時間をかけて勉強することが必ず必要となる。

自分はいきなりJPAで組むことになった。最初はJPQL使わずにJPAPepositoryの標準メソッドだけでごまかしごまかしやっていたが、いろいろ絡み付いて苦しくなった。

だから、やはりJPAをしっかり勉強することが必要になった。勉強してから始めても良いが、どんな問題が出てくるかはやってみないと分からないと思う。

勉強を最初にするか後にするか、いずれにしても時間を割く必要は出てくる。必要工数である。それを割く価値がJPAにはある。

N+1問題

JPA使うと確実に直面する。私のプロジェクトは大丈夫だろうと思っていたが、すぐに出てきたら。関連エンティティの件数が50くらいですぐに重くなりはじめるよ。

JPAを使う以上、N+1問題は避けて通れないからね。

回避方法 Lazy,Eagerは回避方法ではない。後でN回やるか、先にN回やるかだけ。JOIN Fetchが回避方法。JPQLやqueryDSLでJOIN Fetchを指定すること。

@OneToManyは限られたシーンのみ。

Many側のEntityが有限数であるときしか使えない。

最初は親Entityを取得したらMany側の関連Entityもついてるなんて素敵!と思った。

でも、関連Entityがせいぜい10個くらいまでと決まってないと、何個ついてくるかわからない。50個もついてきたら重いです。

ってことで、結局関連Entityも別個でとってくることになった。あれれ?JPAのメリットが大きく削がれたような‥。
Entity→Modelパターン

Entityの構造がDBカラムになる。そこで、DBカラムの変更がUIに影響しないように(?)、EntityをModelにマッピングして(詰め替えて)、Modelを使うというレイヤー分けが採用されていた。

Entity→Modelのとき、Entityごとにマッピング用のクラスを作るのはアホらしい。

まずはBeanUtils#copyを使うことにした。すると、シャローコピーといって、Entity直下のフィールドしかコピーしてくれない。これは、関連EntityをもつEntityのコピー時には役に立たないことを意味する。

関連Entityもコピーしてくれるようなライブラリである、ModelMapperを採用した。(リーダーが使っていたから)

すると、関連Entityをコピーするときに、ものすごい数のJPAが発生した。重たくて実用レベルではない。

レスポンスが遅いUIを更改しようとしているのに、さらにレスポンスが遅くなってしまうところだった。

-JPA/hibernate, Spring framework

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

Eclipse上のSpringBootアプリをGradleでビルドする

no image

ドメインモデルは業務ロジック?

ドメインモデルにはメンバ変数を使った判断・加工・計算を書く。 業務ロジックは処理の手順。 処理の手順をドメインモデルやレポジトリをて組み合わせて実現していく。

no image

SpringFWの中心的役割はDIとAOPである。

Spring Frameworkは山程機能がある   Spring Core はDIとAOP Spring Frameworkの最も核となる部分は「Spring Core」の部分です。 Sp …

no image

Spring MVC HTTPセッションの利用

Controllerクラスにおいてセッションやリクエストに任意の値を格納する方法は、いろいろある。便利なのは処理メソッドの引数にWebRequestをとっておけば、セッション・リクエスト両スコープに対 …

no image

Springframeworkを使うインターネット事業会社

いわゆるWeb企業でも、サーバサイドはSpringframeworkを使っているという企業はあります。 springday2016より http://springday2016.springframe …