スイーツ（笑）と呼ばないで!!

ふと、便利にするための仕組みを無理やり使って不便になることってあるよな、と思ったりすることがある。

例えば、LaravelのController。

Laravelの公式ドキュメントにも

Instead of defining all of your request handling logic in a single routes.php file, you may wish to organize this behavior using Controller classes. Controllers can group related HTTP request handling logic into a class. Controllers are stored in the app/Http/Controllers directory.

と書いてあるように、別にLaravelはControllerの使用は強制してなくて、スタンスとしては、関連するリクエストハンドリングロジックをまとめることができるよ、という感じ。

で、例えば、概念的には3つだけど、システム全体で受け取るリクエストの種類が例えば1つのリソースコントローラーにデフォルトで定義されるactionの数(7つくらいだったけ?)より小さいレベルとかその程度なら、むしろコントローラー分けず、Laravelのbasicなroutingを利用するのは十分ありな選択肢だと思う。

もちろん、サーバーサイドのリクエスト処理が複雑なアプリになってくると別だけどね。

でも、最近はVue.jsとかフロントでいろいろやるアプリとかも多いと思うけど、そうするとサーバーに対するリクエストのパターンなんてアプリの見かけ上の動きよりかなり少ないこともあると思う。

例えば、基本的にAPIでサーバーサイドと連携するアプリなんか、下手すると、リクエスト受付のURLのルールは1つで、単に呼び先のクラスに渡すだけとかあるかもしれない。もちろん呼び先のクラスとかはコマンドパターンとかいろいろ適用して適切に設計したら良い。

ORM周りもそうだし、バリデーション周りのそうだし、Larvalは本当に便利な選択肢がたくさん用意されている、ただ、それらの利用は強制されているわけではなく、必要に応じて利用していくべきものだと思う。と言っても、かなり痒いところに手が届いているので、使って行った方が良いケースがほとんどだけど。

逆に、MVCでMがEloquentとかって決めつけも良くない。それに、なぜか、Controllerで書くかEloquent継承したModel(テーブルと1対1)の2階層しか考えない人もいるけど、普通はそんな単純な構造はなくて、ServiceとかRepositoryとかそういう概念を入れてコーディングをすべきだと思う。その辺も原理主義に陥ってはいけないね。

というわけで、今日は、便利な道具をたくさん集めて逆に不便な状況に陥らないように、たまにセルフチェックしましょう、というお話でしたー

読み返してみると、偉そうだな(笑)

[0回]

• プログラミング
• COMMENT：0