MVCを一通り持つプログラムを部品として、
View→他部品のControl
↑
Control
↓
Model(s)
※最初のCはActionも受け付けるもの。求めるページも受け付ける。
最初のCは「Action」と「欲しいView」と「そのView向けのパラメーター」をクライアントから受け、Actionだけを処理。
Viewは次のCに任せる。
1つめのC→Action処理
返ってくるのは実行結果を表すメッセージ程度。
その後、1つめのC→2つめのC→M、2つめのC→V→3つめのC→…
2つめ以降はView生成。
Cは何をするか。
呼ばれて、M使用、V向けの動的データ用意、Vに渡す。
テスト可能性
テストでは個別に呼べるのが重要。
- Vは動的部分を受けてページを作ればいい。
テストしづらい。一番分けたいところ。 - Mはクラスごとに
普通のテスト。データの。 - CはWebアプリでなくてもActionやページを受けられればいい。で、VやMのスタブを呼べればいい。
呼び出し。フローのテスト。
Controlの呼ばれ方は妥当か
Cはどう呼ばれるべきか。
何が必要か
→必要なものを用意できるクラスが呼べればいい。どうでもいい。
アプリケーション内の各クラスは、必要なものをフレームワークから得る。
envとグローバルなデータ。他のMが生成したデータ含む。
引数は不要。
→Vから呼ばれてもいい。可能。
戻り値は？Vが使うだけ。そのまま使える。
下位のVが作ったHTMLなので。
→Vが受ければいい。
つまり…
クライアント→1つめのC→M→2つめのC
1つめのVは不要。Actionの結果をユーザーに分かるように書いてあればいい。また、あってもいい。
以降は→M→V→3つめのC→…
1つめ…HTMLヘッダー
2つめ…BODY
3つめ…カレンダー
とか
Viewが.tmplを解釈するので、下位Cを呼ぶのもView。
Viewでなければ下位Cの戻り値を.tmplのどこに埋め込むのか分からない。
それを委託…できない。埋め込みには.tmplの解析が必要なので。それを行なうのはView。
V→Cは妥当か？
VもCもフレームワーク(Fr)の一部。どちらもフレームワーク内のクラスを継承するので。そうでなければフレームワークから呼ぶことができない。
つまりV→CはFr→Fr。内部ではC1→Fr→V→Fr→C2になっている。
また、C→M。Mの呼び出しはアプリ定義。Mは自由に作る。フレームワーク外。これ以外のCも自由に付け足してCから好きに呼び出していい。
Webアプリ以外の使い道
Webアプリ専用。
デスクトップアプリならViewもControlも全て不要になるので。
・ページ生成をするViewは不要
代わりになるものは再構成しないといけない。
・Actionの解釈はイベントハンドラーになる
イベントハンドラーからModel呼び出し。
残るのはActionの解釈の後に呼ばれるもの。つまりアプリ本体。UI除く。
つまり
部品（MVCセット）はページ生成用。
アクション処理は複数M、Vなし、''複数C''でできている。
普通のアプリでクリック深度が深いもの。
クライアント→マスターC（フレームワーク）→ユースケースを表す複数C→アクションを表すC複数
Cはツリー構造。
Actionはユースケース名＋Action名で。
Action名はイベントフロー番号でもいい。
Webアプリは大半がページ生成とそれに必要なデータ取得。
それとDB更新などのページと無関係にできる内部処理。1クリックに相当。
ViewとModel
ViewはModelと一対一の対応。Modelにはその表現方法（見た目）があるということ。主従関係はModelが主、Viewが従。依存方向がModel←View。
内容の無い空白ページも1つのView。その中に複数のViewを配置する。
クライアントからのリクエストでView名（またはModel名）とそのパラメーターを与えると、対応するModelが動いて対応するViewがレスポンスになる。
ページを呼び出せばページがレスポンスになり、その中の一部品を呼び出せばそれだけがレスポンスに。
ページ単位でしか動作しないようなクラス構成では破綻するのが目に見えている。セキュリティも一部品ごとに対処。
