なぜSpring Bootで独自のバリデーションを作りたいの？
API開発を複数人で進めていると、APIで同じ項目が出てきます。
- 注文番号（orderNo）
- 商品コード（itmCd）
- 管理番号（mngNo）
- ユーザーID（usrId）
- 等々...
同じ項目であれば、同じアノテーションでバリデーションする事が当たり前。でも、ドキュメントやルールの周知を頑張っても意思疎通がとりきれずアノテーションがズレたものがポロポロと。。
そんなときの解決策の1つとして、カスタムバリデーションがあると思っています。
カスタムバリデーションのパターン
大きく分けて、２つあると思っています。
- 完全オリジナルなロジックが必要なもの
- 既存バリデーションの組み合わせで済むレベルのもの
後者を作成するとき、自前でロジックを組んでいませんか？
**@ReportAsSingleViolation**の利用検討をお勧めいたします。
ReportAsSingleViolation
一言でいうと**「アノテーションをまとめるアノテーション」**
どうゆうことか、以下ソースの後にポイントを記載します。
@Documented
@Constraint(validatedBy = {})
@Target({ElementType.FIELD, ElementType.ANNOTATION_TYPE, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Size(min = 8, max = 10)
@Pattern(regexp = "^[a-zA-Z0-9]*$")
@ReportAsSingleViolation
public @interface UsrId {
/** エラーが発生した場合のエラーメッセージ. */
String message() default "ユーザーIDが正しく設定されていません";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
Constraint(validatedBy = {})
{}なんです。
やりたいことが既存の組み合わせで完結する場合、ロジックを記述するバリデータークラスは必要ありませんよね。
実際、このカスタムアノテーションはアノテーションの組み合わせだけで完結しています。
message() default "xxx"
@ReportAsSingleViolationを利用するとデフォルトメッセージが機能します。これがすごい。
バリデーション動作時には@Sizeと@Patternそれぞれのメッセージ２つは出力されず、自分が設定したメッセージだけが出力されます。
つまりアノテーションがまとまっているんです。
さいごに
@ReportAsSingleViolationを作ればファイル1つでカスタムバリデーション完成です。
カスタムバリデーションって難しそうだから忙しいし、今のプロジェクトへの適用は後回し。。という固定概念を破壊するくらいの手軽さ。
しかし効果はしっかり発揮します。
サンプルではユーザーID 項目を使う複数のDTOクラスやGETパラメータに以下がバラまかれるのを防ぎました。
@Size(min = 8, max = 10)@Pattern(regexp = "^[a-zA-Z0-9]*$")
ルールとして@UsrIdを使おう！というのは必要になります。ですが、特定の引数を付けたバリデーション利用を徹底してください。というルールよりはマシではないか思っています。
是非お試しくださいませ。