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

SpringフレームワークはSpring 4.Xが最新である

これからSpringフレームワークを勉強する人は、Spring 4.X系で勉強しよう。 Spring 4.0がリリースされたのは、2014-09-08である。 Spring 3.X以前は古いので、これ …

no image

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

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

no image

Spring+MyBatisの使用準備は超簡単

1.Mavenの場合 pom.xmlへの記述 <dependency> <groupId>org.mybatis.spring.boot</groupId> &lt …

no image

Spring-data-JPAかmy-batisか

JPAとJDBCは異なるもの。 両方使うことも出きるし、片方だけ使うこともできる。 Springboot使い始めると、JPA使うか否かの選択になります。 言い換えると、SQL使うか否かですね。 私の意 …

no image

Spring MVC フォワード遷移とリダイレクト遷移

フォワード遷移 return “forward:/パス”; // 転送先のリクエストパスを指定 リダイレクト遷移 return “redirect:/パス&#822 …