Re:DRY原則とバリデーション機能

この手の話はよくWebアプリケーション開発で出てくる話だから
自分も少し考えてみる。


まずJavaScriptとサーバで同じバリデーションを
それぞれ行うという点についてだけど個人的には反対。
もちろんJavaScriptでバリデーションをした方が
Webサーバの性能向上に繋がる局面もあると思うけど
それを最初から実装しておくのはYAGNIに反する気がしているし
バリデーションの仕様変更に柔軟ではない。
またWebサーバの性能向上にはソフトウェアの改造以外にも
ハードウェアの増設という手もある。


ちなみにサーバのバリデーションの設定をベースに
JavaScriptのバリデーション用コードの自動生成が行える仕組みなどが
フレームワークとして提供されている場合には
実装を行う必要が無いのでYAGNIには違反しないと思う。


またサーバのバリデーションでは
サーブレットのフィルタを用いて行うという方式にも反対。
HTTPから以外のインタフェイスを受け付けることになった場合に
サーブレットのフィルタだけでチェックを行っていると
そのインタフェイスごとにバリデーションを考える必要性があるため
例えば口座の登録という処理で口座人がnullでないことの
バリデーションをサーブレットのフィルタで行った場合
バッチなどで大量に口座を登録したい局面が出てきた場合に
バッチ側でもバリデーションの方法を考えなくてはならず
インタフェイスが増えればその数だけバリデーションがあちこちに実装されてしまい
仕様変更などに柔軟ではない。


そもそもバリデーションをビジネスオブジェクトの実装から切り離すのは
関心の分離が目的だとするのであれば
ドメインのレイヤでAspectやDynamic Proxyやcommons validatorなどを用いて
バリデーションを行うのが良いと思う。