俺はバリデーションはサーバサイドの入り口で全て行うべきだと思っているんだけど。ブラウザで javascript や maxLength で色々とチェックしているとしてもだ。
真っ先に思い付く理由は手作りリクエスト対策だな。ブラウザを介さずに手作りでリクエストをサーバに送り付けられたら、ブラウザ上のチェックは全て無効化される。他にも色々とブラウザ上のチェックを無効化する方法はある。だからサーバサイドでのチェックは必須だ。
ブラウザ上でチェックをしているのなら、サーバサイドバリデーションでは細かくメッセージの出し分けまでは書く必要が無いというのは正論だと思う。こちらが用意した正規な方法を使わずに不正なリクエストを送り付けて来る奴の為にエラーメッセージを親切に出し分けてやる必要は無い。
ブラウザ上でバリデーションとかをする事には、ユーザが即時に入力ミスを把握する事が出来るというメリットがある。他にもサーバサイドバリデーションでは基本的にエラーが発生しないという状態にする事によって、負荷分散にもなる。逆に使用ブラウザに制約が付いたりクライアントマシンスペックに制約が付いたりする、というデメリットがある。サーバサイドバリデーションを手抜き出来るというメリットは無い。
次に DB サーバで弾かれるから大丈夫という事を言う人が居るんだけども、理想を言うと DB サーバで弾くのは良く無い。DB サーバにそんな事で負荷を掛けるべきでは無い。DB サーバはアプリサーバと比べて拡張性が悪いと思ってる。参照用 DB サーバを作る方法があるとしても、色々と大変な事は細かく考えずとも分かる。DB サーバにチェック制約を付けるのはパフォーマンス的に良く無いし、テストをやり難くするし、項目の長さよりも大きかった場合は自動的にエラーになるというのも、出来ればアプリサーバで弾く事象だと思ってる。それに DB サーバの設定で、若しかしたら入力値がカラム定義よりも長かったら後ろを切って更新する可能性もあったりしそうなのが嫌だ。致命的な問題に 8 桁固定フィールドに 7 桁の入力値が入ってしまうって問題がある。それはチェック制約が無いと弾けない。
それとか他にも問題なのが、入力値が必ずしも DB サーバに使われる訳では無いって事だ。サーバへの入力は OS コマンドの実行に使われるかも知れないし、ファイルシステムへのアクセスに使われるかも知れない。DB サーバで弾かれる事を前提にするのは絶対に良く無い。このフィールドは DB サーバで弾かれるからバリデーションしないけど、このフィールドは DB サーバで使ったり OS コマンドに渡したりするからバリデーションをするって判断をしながらバリデーションを書くのは良く無い。ミスの温床になる。後々の保守でも問題になる。保守している人は実装時のルールなんて細かく知らないから「バリデーションされてるんだろうな」って思いながら修正を行う。それで穴を作り込んでしまいがちだ。それに「必須チェックや属性チェックは必ずやるけど長さチェックはやらない。だけど特殊なケースでは長さチェックもやるように」とか周知すると伝言ゲームの途中で狂う事が多い。そういった周知が通用するのは、ハイレベルで同じ様な思想を持っている人材達が互いに信頼し合ってる様な職場だけだ。寄せ集めプロジェクトではそういうのは無理だと思った方が良い。
