前回までに足りなかった部分を補足してみる。
「Ｖ」に任せる処理はすでにはっきりしているが、「Ｍ」に書くべきか「Ｃ」に書くべきかいまいち迷ってしまうことがある。
そこで方針をより明確にして「Ｍ」なのか「Ｃ」なのか迷わないような線引きを考える。
まず「Ｍ」にはビジネスロジックを書くという方針は決まっているので、「Ｃ」にはそれ以外を書くことになる。
「Ｃ」で受け取った値（リクエストパラメータやフォームデータ）は「Ｃ」内の関数reqdata()によって未定義なら空文字にする処理を施す。（これはビジネスロジックにかかわらず施す処理）
function reqdata($key)
{
return isset($_REQUEST[$key]) ? $_REQUEST[$key] : '';
}
これ以上の処理（必須入力かどうかとか最大文字列長チェックなどの検証いわゆるバリデーション）になるとビジネスロジック側でやるべき範ちゅうに入ってくるので「Ｍ」に任せる。
ということで「Ｍ」内には必須入力などをチェックするis_data()関数を用意することでうまくいく。
function is_data($s)
{
return strlen(trim($s));
}
function seterrmsg($s)
{
$this->val['errmsg']= $s; return false;
}
if (!$this->is_data($s)){
return $this->seterrmsg("必須入力されてません。");
}
if ($this->is_data($s) > MAX_LENGTH){
return $this->seterrmsg("入力が多すぎます。");
}
「Ｃ」側から「Ｍ」にデータ要求してそれを表示させる場合にはhtmlspecialchars()関数など使ってエンティティ変換する必要があるのでこの処理は「Ｃ」で行う。（いわゆるサニタイズなどと言われるもの）
つまり「Ｍ」から返すデータはタグを含まないものかもしくはエンティティ変換済みでタグ付きのものにしなければ処理はうまくいかなくなる。
「Ｍ」から受け取った値のリストを「Ｃ」で表にしたい場合は、「Ｃ」内に表作成関数（エンティティ変換付き）を作るなどするのが素直な解り易い方法になる。