PHPでOOP

PHPでOOP (894ﾚｽ)
上下前次 1-新

614: 2008/12/17(水)20:20 ID:??? AAS
やってみればいいのでは？

615: 2008/12/18(木)01:34 ID:??? AAS
<?php
class Framework{
// コントローラー
public function controller(array $inp){
$model = $this->model($this->di('Action', $this->di('Action_Mapper',$inp));
$this->view($model);
}
// モデル
protected function model(Action $actions){
return $action->do();
省12

616: 2008/12/18(木)01:36 ID:??? AAS
なんじゃそりゃ

617: 2008/12/18(木)01:37 ID:??? AAS
最後の一行間違い

618: 2008/12/18(木)08:21 ID:??? AAS
せめてクラスは３つ以上にするべきだろ。
最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで
出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく
なると思うんだけど。

619(1): 2008/12/18(木)10:48 ID:??? AAS
これはMVCどこがやるのが妥当か？
ってところで迷う。
時々、曖昧なのが出てきちゃう。

620(2): 2008/12/18(木)11:48 ID:??? AAS
>>619
ここで事例を通じて具体的な意見を交わしていけばどうかな？」

例えば・・・
掲示板
■コントローラ：処理の内容を判断するクラス
・プログラムが実行された時、一番最初に実行される
・POSTの値をみて、以下の処理にてどれに該当するかを判断する
　・データを表示する
　・データを書込む
　・編集用のフォームを表示する
省7

621(1): 2008/12/18(木)12:24 ID:??? AAS
>>620

『■コントローラ：処理の内容を判断するクラス』の
> 　・データを表示する
> 　・データを書込む

『 ■モデル：データファイルを管理するクラス』の
> ・ファイルの読み込み、書込みをする

って、意味が重複しているような感じがするのですが...

ならば、
■コントローラ：処理の内容を判断するクラス
　　・モデルからデータを受け取る
省2

622: 2008/12/18(木)12:52 ID:??? AAS
>>621
>>620じゃないけど。
・データを表示する
・データを書込む
・編集用のフォームを表示する
実際に上記の作業をするのは View と Model だよ。Controllerがするわけじゃない。
コントローラーはどれがリクエストされたかを判断して、適切な Model と View を呼び出す。

623: 2008/12/18(木)16:39 ID:??? AAS
>>469は具体的に何処のコードを批判しているのかが分からないので
どなたか解説を頼みます。

624(2): 2008/12/18(木)20:10 ID:??? AAS
MVCモデルでM同士で連携することってあり？
それとも必ずC経由？

C経由の場合、Mをなるべく疎結合になるように細分化してると、
Cの各Actionに書くロジック量が半端なく多くなってくるんだよね。
（Aデータを取ってきてBデータを取ってきてBをCバリデータに通してAとBを基にDを作成して・・・みたいな）
一つのAction内にロジックが増えるのもどうかと思うし、それって新しいモデルじゃんという気もしてこないでもない。

625: 2008/12/18(木)20:23 ID:??? AAS
>>624
俺はM同士で連携するかたちでも良いと思うけどね。
CからMを見た場合、あるまとまった処理単位でメソッドを呼び出す形であることが
重要だと思うから。
CがMを使うときは必ずメソッドＡ呼び出してメソッドＢ、メソッドＣを実行しなければならない。
さらに、そういう３連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが
悪くなると思うから。

626(1): 2008/12/19(金)16:35 ID:??? AAS
試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。

627: 2008/12/19(金)19:23 ID:??? AAS
>>626
うｐきぼん

628: 2008/12/20(土)14:28 ID:??? AAS
>624
変化する内部状態を持つモデル同士で連携させると見通しが悪くなる。
生成してから、（観察される）内部状態が変化しないようなモデルはどこから呼んでもそれほど大きな問題はない。
オブジェクトの生成期間中に（観察される）内部状態が変化するようなモデルは、C直轄にしといた方がいい。

629: 2008/12/20(土)14:34 ID:??? AAS
生成期間→生存期間
なんか寝ぼけてた。

要は変化する「状態」を持っているもの全てはCの管理下に置いておいた方がいいってこった。
「状態」が無いもの（生成時にファイルからデータをロードしてそれっきり、とか）はどこにあったって構わない。
インスタンスの生成を行なうクラスは自分ルールでもいいからある程度絞っておかないと混乱すると思うけどな。

630(2): 2008/12/20(土)15:34 ID:??? AAS
変な質問だけど、OOP での Validator ってのがよくわかんねえ。
is_numeric(); とかをModel内にべた書きしないで、Validatorオブジェクトを通じて、変数の内容を確認すればいいの？

$str = 'string';
$valid =& new Validator();
$valid->isStr($string);

みたいな感じで。
BaseValidator みたいな基本的なチェックをするクラスを作って、継承した先で複雑なチェック用のメソッドを実装させればいいのかな。

631: 630 2008/12/20(土)15:37 ID:??? AAS
引数間違えてる。最後の行。

$valid->isStr($str);

ね。まぁ、別に問題ないが。

632: 2008/12/20(土)15:54 ID:??? AAS
問題はありまくりだろ

633(2): 2008/12/20(土)16:42 ID:??? AAS
>630
外部ﾘﾝｸ:gist.github.com

俺はValidatorクラスはコントローラ単位で実装してる。「入力値の検証」なのだから、コントローラの責任。
Validatorだけ独立させるのはコードの見通しを良くするためであり、責任はあくまでコントローラにある。
ただ、実際にそっからコールするのはModelのメソッド。何が許可されるかを知ってるのはだいたいModelだからな。
たとえば受け付ける値が日付なら、そっから日付クラスのvalidateメソッドを呼び出す（MyDate::validate($string)）。

POSTされる中に列挙型（<select>から送られるような、選択肢が限られているもの）とかがあった場合にこの構成は滅茶苦茶強い。
<select>のためのデータ生成とか、送られたvalueから画面表示用の文字列（「〜モード」とか）への変換を一箇所に集められる。
あと、文字列が決まったフォーマットになっているか調べる場合とかな。

is_strとかctype_stringとかstrlenだけで検証が終わるものはvalidatorクラス内に直書きする。
省1

上下前次 1-新書関写板覧索設栞歴

あと 261 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.031s