LaravelとVCとその他
タグ： Laravel
前記事をどうも誤解している人がいるようですので、追記します。
現在もLaravelはコントローラーを持っていますし、ビューのシステムもあります。ですから後はモデルの解釈の問題です。
シンプルにMがORMをだけを指すとすると、他の役割を持っているLaravelはシンプルなMVCではないですね。MVC+Something elseです。しかも"Else"の部分が大きのです。逆にMがビジネスロジックの全てだと考えれば、LaravelもMVCです。
そこで、LaravelがMVCだ、だからMVCを勉強して実際Laravelのアーキテクチャを理解できるかといえば、できません。モデルの範囲が広すぎて、Laravelが用意しているイベントとか、キューとか細かい部分が見えなくなります。
それにMVCだといっても、モデルの定義が広ければ、複数の開発者が同じシステムを作っても、均一なシステムはできません。十人十色になるでしょう。ですから、MVCであろうと、モデル専用のディレクトリがあってもなくても無意味です。
実際、モデルディレクトリが無くなったことはさして問題になりませんでした。もともとTaylorさんの言っていたことは事前に伝わっていましたから。「modelsディレクトリを削除してあとは作成するシステムに合わせて自由に作る」です。自由に作ることはでたらめに作成するということではありません。開発者もしくは開発チームが既に持っている知識ベースに合わせて作成するということです。
Laravelだろうと、そうでなかろうと、Composerに乗りPSR-4規約を採用しているなら、自分の知識ベースに合わせて作成する自由は持っています。ただ、フレームワークに柔軟性が無ければ、自分が合わせるしかありません。LaravelはEloquentモデルを含め、今までのモデル範疇の部分は自由に作ってねという考えです。
実際に注目すべきは、modelsが無くなったというより、大幅なディレクトリ構造の変更です。そもそも、デフォルトのディレクトリ構造は何を表しているのでしょうか。いくつかのフレームワークを使用した方は薄々感じているでしょうが、そのフレームワークの構造やこう使ってもらいたいというパターンです。
現状のLaravelの構造は、開発者のTaylorさんの見たWebアプリの構造です。Laravelはこう使ってくださいという道を示しています。だからシンプルに、そのまま理解するのが良いのです。ディレクトリ構造も参考資料の一つだと考えましょう。「このディレクトリは何に使うのだろう」と調べれば、より深くLaravelを知ることができます。
あと、足りないのは実現しようとするシステムのロジックです。そこは自分の組み方で組めば良いのです。
もちろん、ライブラリレベルまでばらして、自分の好きなようにフレームワークを組み立てることもできます。そこまでやれば、自由の代償としてメンテの手間がかかります。しかし、そこまでやる人は少数派です。大抵の開発では、自由を謳歌しつつ、枠を大きくこすことはありません。
結局、規約を優勢にしようと、設定を優勢にしようと、modelsディレクトリがあろうと、なかろうと、間違える人は間違えます。app/Userモデルがあるため、Eloquentはトップに置くのだと勘違いする人はいるでしょうね。ドキュメントにロードできるならどこに置いても良いと書かれていいますが、その意味はわからないでしょう。
では、その意味まで丁寧に公式ドキュメントで説明する必要があるかといえば、ないでしょう。フレームワークのドキュメントは設計の教科書ではありません。設計は設計として学ぶべきです。PSR-4のオートロードというより、うまいこと階層化してクラスを配置できるには設計センスが多少は必要です。それはフレームワークのドキュメントの責務ではありません。
しかし、例えば一つの設計手法を完全に学ぶまでWebアプリが作れないというのは厳しい話です。経験から学べることもあります。下手でもないよりはましです。上達するにはやってみるしかありません。そんな時は、コミュニティに尋ねてみましょう。フレームワークの利用者が増えるのはコミュニティの力もあります。
正直な話、99.9%の利用者はLaravelがMVCであるかどうかなんて気にしていないでしょう。多分、他のフレームワークを利用していた人がインストール後に構造を見たら、なんだこれはと思うでしょうね。でも、ちょっといじれば納得してもらえるでしょう。使うかどうかは別として、いろいろ用意されているんだなと。
結局、自由というのは好き勝手にやることも、逆に規約に絡めてやることもできるということです。それを決めるのがフレームワークなのか、それとも開発者側なのかの違いです。
いずれにせよ、完璧なフレームワークなどありません。作るものに合わせてより適したフレームワークがあるだけです。欠点を見れば、どのフレームワークにもあり、長所を見れば、どのフレームワークにも見つけられます。迷ったら、最後は好みです。そんなものです。
追記： Symfonyの開発者、Fabien Potencierさんの書いた記事です。４年前ですね。一部を翻訳します。
「他のフレームワークはMVCにして、それを宣伝しているけど、Symfonyはそうしていない。ドキュメントでも触れていない。MVCと呼ばれようが、呼ばれまいがどうでも良い。だってMVCと言う言葉は余りに意味をもたせられすぎて、誰も同じMVCパターンをもう実装できなくなった。「関心の分離」だけを気にしているんだ。あなたがSymfony2をMVCと呼ぶのであれば、コントローラーとビューのツールを提供していると分かっているんだろう。けど、モデルの部分はしていない。あなたのモデルを自分の手、もしくは他のツール、ORMのようなもので作成するように委ねている。」