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

シナリオクラスでControllerクラスとServiceクラスをシンプルに保つ

no image

Spring-data-JPA使用時のbuild.gradleの設定

1.build.grade compile(“org.springframework.boot:spring-boot-starter-data-jpa”) ********* …

no image

Spring MVC 典型的な階層設計とアノテーション

Spring MVCの典型的な階層設計 階層 クラスに付与するアノテーション コントローラー層 @Contoroller サービス層 @Serivice データ層 @Repository どれにも当て …

no image

Spring MVC HTTPセッションの利用

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

no image

Thymeleaf-SpringMVC <input type=”password”>はth:filedで出力

参考 http://arimodoki.dip.jp/promenade/t_htmlpassword.html ユーザー登録画面で、ユーザー名(ID)とパスワードを入力させて、次は確認画面で両方を表 …