モデルを選ぶのかコントローラを選ぶのか

Question

ある処理をMVCでわけるさい、モデルにわけるべきかコントローラにわけるべきかという判断に悩むときみなさんは、どのような判断基準をもって対処していますか。

Answer 1

場合によります。

ほぼ丸投げの今回の内容だけではこれ以上は回答が難しいです。
きちんとした回答を得たければ前提条件や要件部分を具体的に記載してください。

Answer 2

典型的なMVCのWebフレームワーク前提として回答します。
コントローラーの役目はコントロールです。

迷うような処理は全てModelにぶち込んで下さい。
そっから先は値さえ帰ってきてViewへバインド出来ればどうでも良いので、
Modelへ行った先の抽象化を頑張ってください。

各コントローラの1つのメソッドの行数は10行以内が目標です。
ルーティング、Viewへのバインド、出力方式の決定以外はほぼ何も出来ないと考えた方が良いでしょう。

Comments

[aaaaaaaa]

ご回答ありがとうございます。
ルーティングというのは、こちらのサイト(http://www.atmarkit.co.jp/fdotnet/dotnettips/1031aspmvcrouting1/aspmvcrouting1.html)に記述されている"ルーティングとは、リクエスト時のURIに応じて処理の受け渡し先（コントローラ）を決定すること、または、その仕組みのことだ。"と同じものという認識であっておりますか。

[miyabi-sun]

○○と同じものという認識とかは必要ありません。
出来る事はフレームワークによって違い、設計者の思想が絡んで来ます。
具体的な今使ってるものだけ考えてください。
…という訳で本来はあまり答えるべき質問ではないんですよね。

PHPの場合はroutes.php等のファイルがあって大まかなルーティングはそちらで行うというものが多いかと思います。

でも例えば掲示板に書き込んだ後にF5を押すと再度POST送信ということをさせない為に一度リダイレクトを挟むみたいな小細工をする必要があったりします。
これはコントローラにしか行なえません。

ユーザーに紐づく○○情報が取れなかった時はステータスコード500として扱いなさいみたいな事もコントローラにしか出来ませんし、
Viewへの変数バインドもコントローラにしか出来ません。

他のフレームワークでも機能や仕事量に差はあるかと思いますが、
基本的にコントローラにはコントローラにしか行えない仕事が山のようにあるんです。
もう色んな仕事を受け持っちゃってるわけですね。

なので他のごちゃごちゃしたものがあればあるほど、
コントローラーの本当の役割といったものが他の行のせいで読みづらくなります。
フレームワークによりコントローラーの出来る事は多少ずつ異なりますが、基本はコントローラでやることは出来るだけ最小限にし、他に逃してください。
foreachでオラオラ値を加工するような処理はやっちゃダメですよ。

Answer 3

本当に、”場合によりけり”だと私も思いますが、しいて言えば
・他のコントローラーで使いそうな処理は、モデルに置いておく
・特定のコントローラーでしか使わない処理は、コントローラーに置く
とすると、開発スピードやメンテナンス性が向上するかと思います。

Comments

[aaaaaaaa]

ご回答ありがとうございます。
ほかのCでも使いそうな処理の場合モデルに記述するということですが、それはなぜでしょうか。

[CodeLab]

どのフレームワークなのか？フレームワークの規約やしきたりにもよるかと思いますが、普通に考えて、コントローラーからコントローラを呼ぶというのは、できなくはないと思いますが、あまり美しくないし推奨もされていないと思います。
対して、コントローラが複数のモデルを呼び出すのは、ごく一般的なことかと思います。ですので共通コードがあるのであればモデルに書いて置いた方が見やすくスッキリするだろうという理屈です。

Answer 4

まず、MVCの意味を考え直します。
モデルは構成、ビューは表示、コントローラは処理かな？

これから作ろうとしているものが、何なのか。
もし、モデルとビュー、モデルとコントローラと判断がつきにくい場合は、その処理からモデルの部分、コントローラの部分を取り出して考えます。

特に判断基準というわけではないですが、その処理がやろうとしていることを考え直すようにしています。

今すぐやらないといけないものなのか、表示の部分は後からでもいいのではないか？とか。
あとはクラスにしていつでも呼び出せるようにするとか。

そんなところでしょうか。