バリデーションとは
- 妥当性検査のこと
- 単項目
- 必須／桁数／妥当な選択肢
- 複数項目間の整合性
- 期間：開始日と終了日
- 他のデータとの整合性
- マスタに存在するコードかどうか
- 業務ルールとの整合性
- この項目がAならこちらの項目はCしか選択できない、など
原則
- バックエンドは必須
- フロントエンドはおまけ
ユーザビリティ的には
- 早い段階でエラーを通知してくれるのが嬉しい
- フロントでも結局バリデーションは必要
設計上のジレンマ
- 同じバリデーションを２カ所で実施しなければならない
- PG言語が異なる場合、本当に２重になる
アイデア
- 単項目の制約／データ感の整合性はDBに頼れる
- 不正なデータがDBに格納されないようにする、まさに最後の砦
- せめて500エラーが起きるようにする
- 複数項目間の妥当性／業務ルールには無力
- 複数項目間の妥当性／業務ルールは、最低限、バックエンドでチェックする
- フロントでは「送信」を押した後に表示されるエラーとして表現する
バリデーションエラーをいつ通知するか
- 早い方がいいのは確か
- バックエンドでしかチェックできない事項も、フォーカス外れたときいAPI呼んでチェックする、という実装は可能
- しかし、厳密な実装はとても手間がかかる
- 特に企業向けアプリは項目数が多いので、現実的でない
- 入力中に表示できるエラーと、「送信」を押してから表示されるエラーに分けて考える
- UIを設計するときも、それを念頭に置く
バックエンドのエラーの通知の考慮点
- なるべく多くのエラーを通知してあげた方がいい
- エラー箇所は明示した方がよい
実装について
- PG言語をフロントとバックエンドで統一するのは１つの案
最後に
- バリデーションを決して舐めないように
- 表示タイミングとUIを基本設計時から考えておく
- チェックの種類とチェック箇所を考える（DB/ロジック/フロント/バックエンド)
良い方法あればぜひ教えて下さい！