システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る

BeanValidationのメモ

仕様

Bean Validation specification

参考リンク

JavaEE使い方メモ(Bean Validation) - Qiita

私のBeanValidationの使い方(Java EE Advent Calendar 2013) — 裏紙

BeanValidationの相関バリデーションとそもそもの話 — 裏紙

4.1. 入力チェック — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.3.0.RELEASE documentation

http://fukuchiharuki.hatenablog.jp/entry/2015/01/10/231412

Bean ValidationのGroup sequenceは単項目チェック、相関チェックの順序指定で使うのは止めた方が良さそう - Qiita

Spring Bootで入力値の検証(バリデーション)の順番を制御する - かずきのBlog@hatena

BeanValidationメモ_その1 - 怠惰系エンジニアのメモ帳

Bean Validationでクライアント側のロケールに合わせたメッセージを出力する - Java EE 事始め!

BeanValidationのmessage変数を更に翻訳したい - decadence

Hibernate ValidatorでValidationMessages.properties以外のファイルを使う - Qiita

Validationそのものへの考察

こんな感じのValidationどうかなぁ?「この方が好き」ってあったら知りたいです! - Mitsuyuki.Shiiba

てことでValidationの実装を書いてみた - Mitsuyuki.Shiiba

自分なりの考察

2018/3/19 追記

Validation(検証)とメッセージ出力を混在しないで考え直す

BeanValidationではメッセージ出力まで出来る仕組みまで含まれているけれど、その仕組みを使いこなすのはケースによって無理やり感がでてくるように思います。

とくにWebのエラーメッセージ表示と直結させるときに。

とはいってもBeanValidationを使う多くのケースはFormの検証で、その結果のメッセージをそのままクライアントに返却する、ということで そちらの発想に引っ張られているところが多いように思うのです。

BeanValidation自身は別にWebクライアントの表示のためだけにあるわけではありません。

ツールの用途・目的を考えると、私はValueObjectの型宣言のとして使用するのが良いのではないか?と考えています。

その上でBeanValidationの検証結果メッセージをキーワードとして、Presentation層の目的別にメッセージ変換器を別に設けるというのが「混在しない」というイメージです。

とりあえず、この考えに則って実装を検討してみて、ある程度、まとまったら更に追記をしていこうと思います。