アンチパターンJavaspringjpaspring-data-jpaこれまで使っていて体験したアンチパターン(だと勝手に思っている事例)集。JPAと読み替えてよいものも含まれます。知見少ないので指摘歓迎。Pageable);のようなI/Fだと考えた結果、以下の方法を採用した。「記事」中の「選択したコメント全て」を削除したいModelの要求EntityGraphとしての表現は同じだが意味は異なる。1クラスにView仕様を集めるのは得策ではないかも。spec);やはり全てに適用するのは難しいのでそういうケースでは@Queryを使ったJPQL/SQLを書くピンポイントでのリポジトリのカスタムを選択する。name;}こうすることで、商品情報APIシステムから可能な操作が(完全にではないが)限定され、開発者が考えなければいけないこと、やらなければいけないこと(テストとのパターンとか)が減って幸せになれる可能性が上がる。...}責務が整理されてスッキリ、保守性も上がった気がする小さいクラスになったことでテストもしやすいし変なイージーミスする確率も減るポエムJPAの一番のいいところはこのインピーダンスミスマッチの解消手段を提供している点にあると思っています。完全に解消することはできないのでそういう場合は自分で工夫する必要があります。言われているようなDB製品が変わった場合でも...実装プロバイダが変わった場合でも...はそういう場面に直面したことないので正直どうでもいいと思っています。}}上記みたいにEntityをEmbeddableに含むこともできる。fetchするしか選択肢がなくなる為。}}認証ありのアプリケーションをspring-securityで実装しているとこういう(Entityにo.s.s.c.userdetails.UserDetailsを実装した)コードを書いてしまうかもしれない(つーか書いてしまった)何故ダメかUserDetailsはSerializableである今後ユーザにカラムが100個増えたり、所属部署とか友達ユーザ一覧みたいな関連が増えたらセッションデータが膨らむ。関連EntityにもSerializableが要求されるようになって辛くなる。}}最低でもこんな感じにspring-securityがJPAの事を(あまり)知らないでいいようにしておく。例外(何の例外かは忘れた)が発生となり、open-in-view=falseにしているとview層での遅延フェッチができなくなる為、意図しない追加クエリが発生しなくなる。呼ばれているようにviewの処理中はsessionをopenしておくという機能。実際はサーブレットフィルタ(OpenSessionInViewFilter)によってリクエスト完了までセッションを開いているみたい。これをfalseにした場合、fetchしたはずの関連が実はfetchされないというバグがJPA実装側にあった場合に詰むという問題がある(経験済)ため、盲目的にopen-in-view=falseにするのは危険だと考えています。自分の場合はローカルや検証で使用するprofileのみopen-in-view=falseにする事でエラーチェッカー的に使用することにしています。(最悪のケースでも動く為)view層も含めた結合テストを網羅(追加クエリが発生しない事を保証できている)しているような環境なら大丈夫です。upLoginユーザーは見つかりませんでした。