ModelをLibraryとして使う - とあるIT企業の裏側

典型的なMVCは好きではないです。

ViewとControllerを分けるのはわかるし納得ができる。

あと、古いフレームワークでDBとのクエリをModelでまとめるのも納得できる。

しかし、今時DBとの接続がフレームワークが設定されていので、あえてModelでSQLの記述と接続を記述しなくてもいいかと思います。

古いフレームワークの場合はmysql_connect()を記述してSQLも書いてとなって色々Model上で記述が多くなってくるかと思います。

しかし、最近では細かい記述はしなくてもよく

$results = DB::select( DB::raw("SELECT * FROM some_table WHERE some_col = :somevariable"), array(
   'somevariable' => $someVariable,
 ));

これでコントローラからもSQLが記述できるのでModelで記述する理由もだんだんとなくなってきているかと考えられると思います。

そうなってくるとMVCじゃなくてVCだけでもほぼいいんじゃないか？っていうのが考えです。

VCになると結局さらにファットコントローラの思想に行きついてしまいます。

とはいえ、じゃぁModelは不要って事になるので使わなくてもいいかってなるけどもライブラリとして使用することでいいじゃないかっていうのが今回のコンセプトです。

ライブラリとして使用するつもりが1つのコントローラからのみのアクセスになるってことよくあったり、一回きりの関数の呼び出しが他のコントローラからもModelを呼び出すってこともよくあります。

であれば初めから何がライブラリで何がModelに入れるべき処理っていうのを分けなくてもいいかと思いました。

モダンなフレームワークでのMVCについて懐疑的な意見のページを参照します。

ここに記載されてる事とほぼ同意です。一般的にはMVCにするときれいになるとかロジックはModelに書くべき、ロジックをModelにかけないエンジニアはまだまだ初級レベルみたいな概念がまかり通っているが、MVC自体にメリットがなければVCでもいいのではというのが個人的な意見です。

言いたいことを代替して言ってくれてるからすっきりします。

「LLのフレームワークはコードを整理してるだけ」という意見をModelとControllerの分け方を整理してるだけとくみとって解釈すると、もしコントローラで2000行ぐらいになるファイルになるのであればそれを分割してModelに分けていってもいいかと思います。

変更箇所が多そうな部分を切り出せばバージョン管理上、運用しやすくなるメリットはあるので。

共通ロジックはゴッドオブジェクトとsingle action per controllerの時にまたこの話になると思います。