LaravelとMVC

タグ: Laravel  

養成読本にも書きましたが、ブームしたLaravel3の頃からモデルに関しては何が含まれ、どうすればよいのか意見が分かれていました。もう少し細かく説明しようと思います。

他のフレームワークでは公式ドキュメントでMVCに軽く触れるのが一般的なようです。ところが、MVCの派生パターンはたくさんあり、意見も様々ですから、「これだ」と書かずにぼやかす傾向があります。特にモデルはビジネスロジック全般のことだと匂わせておいて、ORMのサンプルになったりします。

結局、初心者にはよくわからず、ベテランの方々はなんとなく理解できる内容になっています。初心者目線で見ると、結局ORMがモデルのように見えてしまい、ビジネスロジックを書く場所がないため、コントローラに書くファットコントローラを助長します。そして、コミュニティレベルで情報の解説が行われます。

実際、状況はLaravelでも同じです。異なっているのはドキュメントではMVCに直接触れていないことです。Laravel3のドキュメントでは、確か当初「なじみのあるMVC構造をもっている」という書き方をしていましたが、後に削られました。modelsディレクトリが存在し、それがEloquentモデル置き場であったため、いろいろ誤解を招き、議論がされました。

このMVC構造という記述は削られたとき、「モデルとライブラリー」というページで「modelsを削除し、エンティティ、サービス、リポジトリとして表現する」ことを勧めるドメイン駆動開発のスモール版のようなページが追加されました。

ところが、当時のLaravelのユーザー層のスキルレベルと、この記事が意図するところは一致していませんでした。そのため、再度「じゃあ、一体どうしたら良いのか」という質問・議論が起きました。

その後、Laravel4がリリースされ、Taylorさんはプログラム構造の電子書籍を出し、「modelsを削除し、プログラムに合わせてディレクトリを構成する」ことを勧めました。ユーザーのスキルレベルは上がってきたため、その意図は段々と理解されてきました。

そして現行のLaravel5.0では、ついに初めからmodelsディレクトリを削除し、全体の構造をMVCベースから、Laravelの機能と構造を素直に表す形に変更したのです。MVCは関心の分離を促す構造ですが、完全なものでありません。ですから派生パターンがたくさんあります。それに対しMVCではない別の解答をTaylorさんは示しているのでしょう。

Laravel4.0からドキュメントではMVC構造について全く触れなくなりました。実際、コントローラーはありますが、ビューはPHPコードを含んだHTMLで表されます。モデルという解釈の広いものを置く場所は、もう5.0にはありません。各開発者の脳内モデルをPSR-4規約で表せばよいのです。

MVCのコントローラーとは、Laravelのコントローラー中のアクションメソッド、解釈によりコアのRequestやルーターにあたります。 MVCのビューは、resourcesディレクト下のビューファイル、解釈によりコアのViewクラス、Responsクラスにあたります。 Mのモデルはドメイン駆動開発にしたがって用意するもよし、他の開発技法を使うもよし、自分のオリジナル作法で書いても良しです。ただし、Eloquentモデルだけを示すものではありません。限定してしまえば、また同じ過ちが繰り返されます。

追記:Symfony2のようにMVC構造ではないと公式に言ってもらうだけで、だいぶ状況は改善すると思うのですが。Taylorさんにどう考えているのか尋ねていますので、運良く答えがもらえたら、また報告します。