入力チェックってどこでやればいいんだろう
 日記

　いろんなフレームワークで、入力チェックが簡単に作れそうに見えるいろんなやりかたをしてるわけです。たとえば、定義ファイルになんか書いとけば勝手にやってくれるとか。
　でもそういうもので、まともに使えるものにお目にかかれたことは一度もないんである。

　最近やってる.NETでは、ビューにフォームと一緒に検証コントローラを配置しといたりするわけだけど、もちろん案件の要件は.NETのために作られたわけではないので、うまくいかないケースがあったりする。
　そりゃあプログラム書いてるんだから、できないことはない。やりようはいくらでもあるわけだけど、でもそれをやるならはじめから、.NET組みこみの検証コントローラなんかつかうなよって話になる。
　そんなわけで、ほとんどの場合は、というかまず確実に、フレームワークが用意した入力チェックを使わずに、はじめから自分で作ったほうがわかりやすかったりする。工数も確実に少ないし。
　もちろん、フレームワークの作者が本気で使いこなせばうまくやれるんだろうけど。残念ながら、フレームワークをつかった開発は一期一会だ。使いこなしたころには終わってしまう。少しでも難しかったりドキュメントが足りなかったりしたら、もう使ってもらえないと考えるべきだ。

　まあ、.NETの場合は特殊っていうか、問題がありすぎる気がするので(笑)他と同列に扱っちゃいけないようにも思うけど。あの場合はきっと、そもそも、ビューに検証コントローラを配置するという考えかたが問題だ。
　で他のフレームワークを考えてみると、コントローラに処理を渡す前に検証を終わらせておこうという方針で作られてるものが多いわけだけど、その考えかたにも問題ある気がする。

　理屈の上でレイヤ分けするなら、入力チェックはプレゼンテーション層にあればいいわけで、コントローラの上にもう一層作る必然性は別にない。と思う。
　というか実際の話としては、MVC的なあれでいうなら、ようするにモデルに処理を渡す直前にやりたい。そうするのが、層分けが明確になってわかりやすい。
　ってことはコントローラの中なのだ。
　しかも、よく思うんだが、そこはオブジェクト化したりフレームワークに組みこんだり、いろいろしないでほしい気がする。どうせ要件（と上流工程の人）はもっと非論理的だし。フレームワーク組みこみの方法ではどうせ対処できなくなるし。
　全部staticのユーティリティクラスでいいのだ。それを一つ一つ呼ぶ処理を、ずらずら書き並べればいいじゃないか。それでいいじゃないか。

　最近（職場の中で的には）オブジェクトの人になっちゃってるわたしですが。オブジェクトに反対したほうがいいこともある。
　っていうか.NETからは多くの反例を学べる気がしてるこのごろ。要は個人的に肌に合わないって話だけど。