ダイコン時代の設計手法 - Validation
ダイコン時代のアーキテクチャでは、各層がきちんと
役割分担をすることが重要だと書いたのですが、
それは、Validationにももちろん当てはまります。
各層でどのようなValidationを行うのかを
きちんと決めておく必要があります。
Validationはつぎのようなタイプに分けられるのではないかと思います。
- 形式的なもの
- 文字列を本来のオブジェクトの型に変換するのに必要なValidation
- xx以上xx以下、xxは必須のようなもの
- サービスの事前条件をクリアするために必要なValidation
- サービス層で行われる業務ロジック的なValidation
2が難しく感じるかもしれません。
事前条件を大雑把に言えば、あるメソッドを呼び出すために
引数が満たしていないければいけない条件です。
例えば、割り算を行うメソッドint divide(int a, int b)が
あった場合、b != 0というのが事前条件です。
すっごく大雑把な言い方をしているので、できれば
DbC(Design by Contract)の文献を読むことをお勧めします。
UI層は、サービス層を呼び出すところまでが
自分の役割なので、サービス層の事前条件を満たすためのValidationは、
自分でおこなう必要があるわけです。
「やっぱり何言ってるかわからないよ」というお叱りの声が聞こえてきそうです。
上記1,2,3を現実的に書いてみると、
- UIのフレームワークで用意されているValidationの仕組みを使って行う
- 上記以外のデータベースにアクセスしないValidation
- データベースにアクセスするValidation
というふうにわけてもほとんどの場合大丈夫ではないかと思います。
1はUIフレームワークを使って行います。
2はUI層で行います。プレゼンテーション層のモデルで行うことが多いと思います。ただし、フレームワークによります。
3はサービス層で行います。
ユースケースには、すべてのタイプのValidationが、一緒に記述されて
いるので、どのタイプなのかを見極めることが重用です。
最近のWebアプリは永続化にかかわる部分とValidationにかかわる部分で
ほとんど占められているので、Validationの扱いを間違えなければ、
たいていはうまく良くと思います。
