今日は本当はFuelPHPでアプリケーション作成していこー!という記事を書く予定だったけど、
作ってる途中でFuelPHPのViewModelを調べてたら記事を書きたくなったので、今日はViewModelについて書こうと思う。
最初にViewModelって名前を見た時にはMVVMをサポートしているのかと思った。ViewModel使ってResponse返すとKnockout.jsのバインドでもしてくれるのかと。
でも実態は思ってた使い方と違ったのでちょっとまとめておこうと思う。
とりあえず図にしてみた。
要はView作る為の処理はViewModelに任せてしまってControllerからModelを呼び出すのは永続化とかのViewに関わらない処理のみにしてしまおうという事。
こうしておけばModelの責務が軽くなるのでModelの肥大化を避けられるという訳だ。
オブジェクト指向の原則である、Command-Query分離の原則をより分かり易い形で実装出来る事にもなるのでいい感じだ。
確かにWebシステムにおいて、取得したデータってViewでしか使わないし、登録・更新の為に一時的にSelectする場合なんかだとModelの中で完結させるべきだから、こっちの方がしっくりくる。
でもこのモデリング、何て名前にすべきなんだろ…MVVMC?
MVVMとは全然別物だし、MVMCとか?
ViewModelとViewを合わせてViewって扱いで普通にMVCでいいのだろうか…
ちなみに超個人的見解なので、それは違うよ!とか、コイツ分かってねーな。とかツッコミどころが有ったら遠慮なくコメント下さい。
ViewModelの仕様を見て、こういう使い方…なんだよね…?と考えただけなので正しい使い方なのかどうかはあんまり自信が無い…
作ってる途中でFuelPHPのViewModelを調べてたら記事を書きたくなったので、今日はViewModelについて書こうと思う。
ViewModelを使った場合のモデリング
最初にViewModelって名前を見た時にはMVVMをサポートしているのかと思った。ViewModel使ってResponse返すとKnockout.jsのバインドでもしてくれるのかと。
でも実態は思ってた使い方と違ったのでちょっとまとめておこうと思う。
とりあえず図にしてみた。

要はView作る為の処理はViewModelに任せてしまってControllerからModelを呼び出すのは永続化とかのViewに関わらない処理のみにしてしまおうという事。
こうしておけばModelの責務が軽くなるのでModelの肥大化を避けられるという訳だ。
オブジェクト指向の原則である、Command-Query分離の原則をより分かり易い形で実装出来る事にもなるのでいい感じだ。
確かにWebシステムにおいて、取得したデータってViewでしか使わないし、登録・更新の為に一時的にSelectする場合なんかだとModelの中で完結させるべきだから、こっちの方がしっくりくる。
でもこのモデリング、何て名前にすべきなんだろ…MVVMC?
MVVMとは全然別物だし、MVMCとか?
ViewModelとViewを合わせてViewって扱いで普通にMVCでいいのだろうか…
ちなみに超個人的見解なので、それは違うよ!とか、コイツ分かってねーな。とかツッコミどころが有ったら遠慮なくコメント下さい。
ViewModelの仕様を見て、こういう使い方…なんだよね…?と考えただけなので正しい使い方なのかどうかはあんまり自信が無い…
https://github.com/fuel/core/wiki/Changelog-v1.7.2
ちょうど最近にフォーラムで中の人がViewModelの解説をしてました
http://www.fuelphp.com/forums/discussion/13076/viewmodels
> ViewModelとViewを合わせてViewって扱いで普通にMVCでいい
で合ってるんじゃないでしょうか。
新しい名前のPresenterはMVPから取ってるっぽいですが、FuelPHPの場合MVCのCが殆どそのまま残ってて、いわゆるMVPを採用って訳でもないので。
表示用のデータ整形処理(ロジック)はViewと密接に結び付いたものですが、ViewへHTML出力処理(表現)と混ぜこぜにして置いてしまうと実用上の問題があります(デザイナーとの共同作業、SmartyやTwigなどロジックの分離を前提としたテンプレートエンジンの利用など)。
それで他のMVCフレームワークだと整形処理をコントローラに置いたり、下手するとモデルからのデータ取得処理のところに置いちゃう人までいるんですけれども、表示用の整形処理がViewに密接に結び付いたものな以上、本来コントローラやモデルに置くのもちょっと気持ち悪い訳です。コントローラやモデルのViewとの結合度が上がり、同じデータの表示方法を変えるだけでコントローラやモデルを変える事になります。
表示部分をデータ整形処理層(ViewModel)とテンプレートエンジン層(View)の二段構えにしてしまえば、たとえばスマホ用/PC用の切り替えとかもコントローラ/モデルは気にせず表示部分変えるだけで作れて、クラスにしてるから似たような画面の処理をまとめるのに継承やTraitみたいなPHPの機能も使えるよ、というのがViewModel/Presenterですね。
MVC分離にも表現とロジックの分離にも賛成、でも「Viewにあらゆるロジック(表示用であっても)を置くな」は不便なので、Viewで更に表現とロジック分けてみました、が近いと思います