WEBアプリのMVCについて質問です。

一般的なフレームワークを用いたMVCについて質問です。

例えばM、これはモデルですね。
普通DBヘの接続はモデルでおこないクエリの発行もモデルで行いますね。
その後、クエリ実行後の結果をコントローラー側に返すと思います。
このとき、普段わたしはモデル上ではDB空の目的のデータをいっさい処理せずそのまま
コントローラに返します。

返り値として、何かしらの一覧データを取得するものとします。例えば
[
{name : "タロウ" , age : "２０","town_id" : 10,"city_id" : 49, "prefecture_id" : 23},
{name : "花子" , age : "２０","town_id" : 10,"city_id" : 49, "prefecture_id" : 23},
{name : "邦夫" , age : "２０","town_id" : 10,"city_id" : 49, "prefecture_id" : 23}
]
といった感じで特定の組み合わせのハッシュを多次元配列（リスト）的にラップしたものがかえりますよね。

そして、上記データをコントーラー側が受け取り、さぁいざビューへと受け渡す際に、どの程度コントローラでデータの
加工を行うものかが気になっています。
たとえば上記データでは「県市町」のデータがユニークなIDとして保持しています。このままでは「タロウ」が
どの住所なのかがわかりません。どこかで「県市町」のデータリストを受け取りループで一致する住所を取得する
必要があります。
それをコントローラあるいはビュー・・・・どちらで行うのがMVCとして正しいのでしょうか？多少のループなら
ビュー側で行うのもありかとおもいますが、はやりビューがループであふれかえるのは作業しにくいですよね。
MVCの基本だとは思いますが、rubyやPHPなど、フレームワークごとの細かい思想はあるでしょうが
一般的なMVCとしてみるとどうでしょうか？

ちなみに、モデル内でjoin などつかって県市町のテーブルをくっつけるのはここでは考えないものとしてください。

個人的にはビュー内では大きなループ一度ですませたいものですが　・・・。

No.4 ベストアンサー 回答者： notnot 回答日時： 2013/07/26 23:49

No1です。

＞コントローラは完全に、モデルで取得したデータをビューへ橋渡しするためだけに存在するというような意味合いってことでしょうか？

補足へ回答しようとしたら、すでにNo2の方が書いてましたね。

ユーザーのGUI操作に伴って、適宜モデルやビューを呼び出すのがコントローラーです。
ビューから直接モデルを参照した方が良ければすればよい。

あまり、「MVCモデル」にこだわらず、それぞれのフレームワークの枠組みに従って開発すれば良いと思いますよ。フレームワークのルールで開発するとおそらく一番効率がいいわけなので。
Railsだと、Model+View+Controlでなく、Database+Template+Processingと思えば良いのかな。

No.3 回答者： iioi 回答日時： 2013/07/26 23:06

FuelPHPでは質問者の書いているような処理はMVCだけではなくてViewModelがありそこでこのような実装をすることができるようになっている。

No.2 回答者： Yune-Kichi 回答日時： 2013/07/26 02:56

>>MVCモデルの場合は、ビジネスロジックはModelの中に実装します。

>とありますが、
>コントローラは完全に、モデルで取得したデータをビューへ橋渡しするためだけに
>存在するというような意味合いってことでしょうか？

コントローラは入力をモデルに引き継ぐのが役割です。
Webであれば，ページ遷移まわりはコントローラの役割になります。
ページ遷移に伴って，入力がくっついて来ます。

ビューの更新は，本来的にはビュー自身の役割です。
ビューがモデルの変更を検知して (e.g. Observer Pattern)，更新します。
さらに，ビューはモデルを直接参照します。
ただし，Web MVCではこの更新の仕組みを使うことは無いでしょう。
そもそもモデルの変更，ということがありえない世界なので。
それもあって，コントローラーなりMVCのフレームワークなりが，ビューへ描画要求を出すことになります。
# 大元のMVCは状態を持つ環境で生まれています。HTTPのように状態を持たない環境でMVCをやろうとすると，どこかに歪みが出てきます。


MOVEは望まれなかった子 - the sea of fertility
http://ugaya40.net/architecture/dis_mov.html
にもあるのですが，元々MVCはPDSによる責務の分離が根本の思想です。
表示に関わることであればP側，つまりVまたはCで処理し，そうでないならばD側，つまりMで処理します。
ちなみに，CにPLを持たせた場合，MVCとは別の名前が付いています。
# MVP (Model - View - Presenter)

この回答へのお礼

ご回答ありがとうございます。

> 大元のMVCは状態を持つ環境で生まれています。HTTPのように状態を持たない環境でMVCをやろうとすると，どこかに歪みが出てきます。

なるほど、WEBアプリにおける
MVCそのものが後発だったため、本来のMVCとはことなるのですね。

WEBアプリで正しいMVCで設計しようとしても、
もともと無理があるということなのですね。

お礼日時：2013/07/26 22:44

No.1 回答者： notnot 回答日時： 2013/07/25 23:10

Ruby on Rails のようにMVCモデルでないにもかかわらず、Model View Controlという用語を使っているフレームワークがあるため、混乱している人がいるようです。

MVCモデルの場合は、ビジネスロジックはModelの中に実装します。あなたの考えはMVCモデルから外れています。
もちろん、別にMVCモデルに従って設計しなければならないわけではないので、自分の好きなように設計すれば良いかと思いますよ。

この回答への補足

ご回答ありがとうございます。

>MVCモデルの場合は、ビジネスロジックはModelの中に実装します。
とありますが、
コントローラは完全に、モデルで取得したデータをビューへ橋渡しするためだけに
存在するというような意味合いってことでしょうか？

補足日時：2013/07/25 23:16