MVCってなんやねん

blog.codecamp.jp
Controllerがユーザからのリクエスト(URLにアクセス)を受け取ります。次にControllerはリクエストに対し必要な処理をModelへ依頼し、Modelは処理を行いその結果を返します。必要な処理が終わったら、ControllerはViewへユーザへ表示するHTML内容を依頼し、Viewが表示内容を返します。

blog.codecamp.jp
「ユーザからの入力を受け取るControllerファイルはドキュメントルートに置きます。それ以外のファイルはURLから直接アクセスできる必要はありませんので、ドキュメントルート外にファイルを置きましょう。」
「一般公開するファイルは必要最低限にする」
blog.codecamp.jp

white-bear.info
MVCフレームワークRuby on Railsが発祥のようで、そのRuby on Railsでは、M(モデル)はデータベースのテーブルをそのままオブジェクトとして扱います。テーブルAにはモデルAオブジェクトが対応し、テーブルBにはモデルBオブジェクトが対応するというカンジです。

まず、メインの処理となるビジネスロジックはモデルに書きます。たまにコントローラーに書く方もいますが、基本的にはモデルが担当するべきでしょう。具体的には、モデルにメイン処理のメソッドを実装して、コントローラーではこのモデルのメソッドをコールするような形式が良いかと。そしてモデルのメソッドから得られたデータをビューに渡して表示するといった流れになります。

モデルをテーブル(ファイル)に対応させる方法
Railsにおける「モデル=テーブル」という考え方でMVCを構成します。
テーブル(ファイル)ごとにオブジェクト生成→メソッド呼び出しといった流れになるので非常に整理しやすくなります。ただ、テーブルと関係のない処理をどこに記述するのかといった問題があります。この場合、新たにクラスを用意してそこに記述するか、とりあえずコントローラーに記述することになります。

モデルをコントローラーに対応させる方法
この方法はコントローラーに対して必ずモデルを用意するので、処理やページごとにモデルを作るイメージになります。複数テーブルにまたがる処理やテーブルに関係のない処理などもモデルに記述すれば良いので、メソッドを記述するべきクラスに迷うことはありません。ただ、同一のテーブルにアクセスしているにもかかわらず、あちこちのモデルに同じような処理が記述されるようなケースが発生することがあります。

→テーブル単位かコントローラー単位か

コードの再利用性と作業分担、セキュリティ対策ができるMVC