ConverterとValidatorについて

T2Framework


どうも。二日酔いだと思ったら風邪だったDQNです。
DQNなのでConverter/Validatorについて書きなぐってみるよ。


T2はポリシーでもあげているとおりConverter/Validatorについては以下のような感じです

  • Converterというかコンバージョンは求められたら最小限に。適度なバランスを探す。
  • Validatorはしないから渡ってきたところで好きな順序で好きなものを使ってやってね


特にConverterをどのような扱うかは結構考えてたけど、あるときから
ConverterもValidatorの一種として捉ええるようになった。
昨日、小林さんとValidatorってさー的な話をしていて、同じような考えをもっていて
ますます確信をもつようになった。
つまり、値の検証をしてそのまま値を返すのがValidator、値の検証をして変換という
付加機能をつけて値を返すのがConverterだ。つまりConverterはValidatorの特殊形態と
捉える感じ。自分的にもこの捉え方はかなりしっくりきた。


元々HTTPから渡ってくるのが全てStringなのに、そこからConverterとValidatorを
フレームワーク内で全てやってしまうのはやりすぎなんじゃないかなというのが
オレの今の考え。実際にConverterやValidatorで、あるフィールドAに対しての変換が
失敗しても次の項目の検証も行いたいとか、相関的な変換や検証や順序が重要とか、
年月日の3つの項目で先にそれぞれの項目でValidationしかけたあとにDate型に変換なんていう
ありがちな事例を考えるだけで、ユーザにとってValidatorは最大限コントローラブルであるべきだと思う。


Validationは奥が深い。


だからT2では、Converter/Validatorはコントローラブルであるべきなので
フレームワーク内部でやるべきじゃないというポリシーを貫こうと思う。


なんかもっとよいやり方が見つかって、ユーザにとってコントローラブルかつ
フレームワーク内部にささってないValidatorの方法が見つかったら、
拡張として何か出すかもしれないが、それも内部にいれずに別個のValidationフレームワークと
すべきじゃないかな。
ひとまず、淡々と「つなげる・つながる」部分をT2ではやり続けたいと思う。


P.S.ちなみにサンプルとかにはValidatorの簡易フレームワークみたいなのを
つけてみたいと思います。T2はサンプル超重要なんです。