ポンコツPdMの開発メモ

2026/11/4

Spring Bootの@Validと@Validatedの違い｜必須チェックが効かない原因と使い分け

AIによる要約Spring Bootの@Validと@Validatedは、通常の入力検証とグループ指定で使い分けます。特に「@Validated(CreateGroup.class)へ変えたら@NotBlankが効かない」場合は、共通制約のDefaultグループが検証対象に含まれているかを確認してください。登録・更新の入力例と実行結果で違いを確かめます。 Spring Bootで入力チェックを調べると、@Validと@Validatedの両方が出てきます。普通のFormやRequest DTOを検証す ...

設計・テスト・レビュー

2026/11/4

Spring BootのFormとDTOの違い｜Serviceへ渡すクラスを分ける判断

先に結論FormをServiceへ直接渡してよいかは、画面の入力契約とServiceの業務処理の契約が同じかで判断します。画面専用項目・型・検証ルールがずれる、APIやバッチからも同じ処理を呼ぶなら、Service用のDTO／Commandへ変換します。小さい機能で前提が一致している場合まで、名前だけを変えたクラスを機械的に増やす必要はありません。 FormをそのままServiceへ渡すとレビューで指摘された。でもDTOを作っても同じフィールドをコピーするだけに見える。この記事は、FormとDTOを分ける ...

実装・エラー解決

2026/11/4

Spring Bootの@ModelAttributeとは？Formに値が入る仕組みと使い方

AIによる要約@ModelAttributeは、リクエストパラメータをFormクラスへ詰めたり、画面へ渡すモデル属性として扱ったりするために使われます。Thymeleafのフォームでは、Form名、フィールド名、Controllerの引数名がずれると値が入らない原因になります。 Spring MVCの画面フォームを触ると、@ModelAttributeというアノテーションが出てきます。利用者登録の画面を例に、初回GETで部署を「開発」、利用枠を1で表示し、POSTで利用枠に abc が送られたら、入力し ...

実装・エラー解決

2026/11/4

BindingResultの使い方と注意点｜@Validの直後に置く理由

AIによる要約BindingResultは、@Validで検出した入力エラーをControllerで受け取るための引数です。重要なのは、@Validを付けたFormの直後に置くことです。順番を間違えると、期待通りにエラー処理できません。 Spring MVCで入力チェックを実装すると、@Validと一緒にBindingResultが出てきます。利用者登録のControllerに Model を足したところ、利用枠0を送ると入力画面へ戻らず400になったとします。同じフォーム、同じ入力で、BindingR ...

設計・テスト・レビュー

2026/11/4

@RequestParamが多すぎる時はどうする？Controller引数の整理方法

AIによる要約@RequestParamが増えすぎたControllerは、読みづらく、修正漏れも起きやすくなります。検索条件や入力項目がひとまとまりなら、Formクラスや検索条件クラスへまとめることを検討します。ただし、何でもまとめればよいわけではなく、関連する値だけをまとめるのが大事です。検索画面や一覧画面を作っていると、Controllerの引数に@RequestParamがどんどん増えることがあります。注文一覧のキーワードと状態に、開始日・終了日・担当者・ページ番号が加わったとします。既存の検 ...

設計・テスト・レビュー

2026/11/4

Spring Bootで入力チェックが重複する｜ControllerとServiceの分け方

先に結論画面とAPIの両方に同じ重複チェックを書いているなら、メール重複などの業務判断をServiceへ集約します。必須・文字数・形式は各入口のForm／Requestで検証し、Controllerは結果をHTMLやJSONへ返します。同じ業務エラーでも、画面の項目エラーとAPIの409応答は分けて扱えます。登録画面とAPIを作ったら、メール重複のif文が両方にできた。Serviceへ移すと、今度は例外が画面へ表示されず500になる。この記事は、そのような入力チェックの重複とエラー応答の分け方を整理しま ...

実装・エラー解決

2026/11/4

Spring Bootの@RequestBodyとは？JSONを受け取る使い方と注意点

AIによる要約@RequestBodyは、HTTPリクエストのボディに入っているJSONをJavaオブジェクトへ変換して受け取るために使います。クエリ文字列やHTMLフォームを受けるためのものではありません。APIの入口ではRequest DTOとセットで考えると安全です。 Spring BootでAPIを作ると、@RequestBodyがよく出てきます。利用者登録のAPIにJSONを送って400になる場合、Controllerの登録メソッドにブレークポイントを置くだけでは原因が見えません。このサンプル ...

設計・テスト・レビュー

2026/11/4

Spring BootのServiceに業務ロジックを書く理由

AIによる要約注文取消では、対象を取り出し、取り消せる状態かを判断し、成立した場合だけ保存します。この順番をServiceのユースケースにまとめると、HTTPを介さず同じ取消と保存の契約を確認できます。注文100は出荷待ち、101は出荷済み、102は取消済みです。この機能では出荷待ちだけを取り消します。状態を変えられない注文と、存在しない注文も、それぞれ結果を決めます。ここでは、HTTPコードを使わずに「どの状態なら変わるか」「失敗した注文は保存されないか」を調べます。この記事のポイント出荷待ちの ...

設計・テスト・レビュー

2026/11/4

Spring Bootの@Transactionalはどこに付ける？

AIによる要約Spring Bootの@Transactionalは、基本的にRepositoryではなく、業務処理のまとまりを表すServiceメソッドに付けることが多いです。どこからどこまでを1つの更新単位にするかを決めるためのアノテーションであり、何となく付けるものではありません。 Spring BootでDB更新を扱うと、@Transactionalというアノテーションが出てきます。初学者は、とりあえずRepositoryや更新メソッドに付ければよいと考えがちですが、現場では「どこからどこまでを ...

設計・テスト・レビュー

2026/11/4

Spring BootのDTO変換はどこでやるべきか

AIによる要約注文の照会・取消では、内部の注文、Serviceの結果、公開JSONを分けます。取消可否を決めるのは業務側で、DTOは決定済みの値を公開する3項目へ変換します。注文データには、画面へ返さない internalReference があります。一方、APIで公開するのは id、status、cancelable です。 DTO変換の置き場所は、条件の長さより「表示だけを変えるのか、業務上の答えを決めるのか」で考えます。この記事のポイント APIへ返す項目を3つに絞る業務上の取消可否をSer ...

« Prev 1 … 10 11 12 13 14 … 19 Next »