Laravel 使いが Django を触って思った感覚的違和感と混乱したパートについて

Laravel 使いが Django を触って思った感覚的違和感と混乱したパートについて

Laravelを触り出してもう4年以上経過しました。
すっかりLaravelerな私ですが「自然文字列合成でSEOワードを入れた商品説明文を自動生成したい」という野望の為にpythonを勉強しております。

で、身内的企業から受けたWEBサイト作成のお手伝いを「Djangoで書いてしまえば勉強と収益が一石二鳥だ」とDocker×Djangoに乗り出したのですが、最初は違和感&混乱ばかり。
そんな現時点までで悩みつまづいた事柄をまとめてみたいと思います。

感覚的に「正しいのか？」と悩んだ事

戸惑いながら進んだその順を追って書いてみました。

とある方から「Laravelばかり触ってると他で書けなくなるよ」と言われていたのですが、動き出した今その気持ちよくわかります。
「Laravelって自由度高いわりに自動的にしてくれる処理も多かったんだなぁ～」と痛感してます。
命名規制とディレクトリ構造を守れば大概の事はお任せ出来てましたからね。
ただし、その分『クセ』も強かったのでしょう。

Djangoに触れるとディレクトリ構造での違和感受けまくりです。
その一番最初が『プロジェクトの中に配置されるプロジェクト名ディレクトリの存在』です。

ディレクトリ構造が違う根本原因

DjangoとLaravelではその本体がどこにあるかという点が構造の違いを生む根源の様です。
Laravelの場合、フレームワークそのものをプロジェクトの中に内包しています。
一方、Djangoの場合はフレームワークは別の場所（pythonディレクトリ内）に存在しています。

この違いでプロジェクトのファイルサイズは結構違います。
Laravelだと1枚ペラモノでも500KBくらいになるのに、Djangoだと50KB程度。
Laravelでは『基本的に弄らないディレクトリ』が存在しますが、Djangoではそんなことは無いようです。

この違いが多分ディレクトリ構造の違いを産んでいるのだと思います。
Laravelはソフトウェア的で【目的別】にディレクトリが分かれますが、Djangoでは【サイト構造】がディレクトリに現れています。

プロジェクトの中に配置される【プロジェクト名ディレクトリ】の存在

最初はこれが正しいのか悩みました。「同じ名前だよ？」って。

Laravelでは命名規制による各ファイルの連携が行われる為『フォルダ名が同じ』という点に強烈な不安を覚えました。

「プロジェクトの各設定をまとめたデータが【プロジェクト名ディレクトリ】にある」と解釈出来てやっと「当たり前」という感覚になれました。

ディレクトリ構造の違和感

Laravelで慣れた人は先に触れた【目的別】の構造に馴染んています。
その感覚でDjangoを見るので「viewとModelが同じディレクトリ？」「モデルがアチコチにあってわかりずらい」とか思いました。
まぁフレームワークが違うので「そういうモノ」として覚えるしかないんですけどね。

逆に「Djangoを先に触るとLaravelなんてわけわかんないんだろうなぁ～」と思いました。
「この画面操作するんだから同じディレクトリに入れとけよ！」とか思うんだろうなぁ～と。

ルーティング設定

ここら辺は「Laravelって楽なんだなぁ」と痛感しましたね。
例えば、CRUDそれぞれのViewがある時。Laravelはroutes\web.phpに1行加えるだけで【resources\views\hoges】ディレクトリの index.php/edit.php/create.php/show.php と関連付けてくれます。

これがDjangoだと各々の関連付けが必要になるので4行必要。
ページ数増えると結構大変だなぁと感じました。
というか、Laravelの命名規制に髄する機能スゲーと思う。

Applicationという単位の考え方

いろいろ学んでくると、ここら辺はDjangoが優れてると思う今日この頃です。

最初によくわからなくなったのがこれ。

Laravelの場合、Viewはコントローラー毎に作成されます。なので、Viewsディレクトリに(基本的に)Controllerと同じ数のディレクトリが生まれます。
同じことをDjangoで行うとプロジェクトディレクトリの直下にすっごい数のディレクトリ出来る事になります。
でも、Djangoではアプリケーション内に子アプリケーションが存在していてもいいみたいですよね。

まだそこまで進めていませんが、動作軸のディレクトリ構造を作れるのなら動作毎の操作許可って簡単に組める気がします。Laravelはここら辺のコントロールが面倒でしたが、親で切断すれば子に繋げないという構造を作れればcontrolする数が減るのでうれしいです。

uWSGIという魔物の取り扱い

ホントこいつが一番嫌いかも。
Laravelだと直接WEBサーバー(Apache/Nginx)とつなげてしまいます。
なので、動かなければどこが悪いか判り易かったのですが、Djangoだと悩む箇所が1つ増えてしまいました

ここにDockerが加われば更にもう一つ追加なので場合分けに悩みます。

statickフォルダの取扱い

これもLaravelが楽だったと思うパーツです。
Laravelさんは勝手にやってくれてましたからね。

publicに放り込んでおけばよかったLaravelとはだいぶ違います。
staticが動かないとCSSとか読めないですから大問題です。

開発環境を問わずPythonを使い方向けのフレームワーク

LaravelそっくりなPython製Webフレームワークがありました。

Masonite

ディレクトリ構造とかマジで同じ。
これだとLaravelerの方は悩む事少なくPythonで組めそうです。

まとめ

「郷に入っては郷に従え」でDjangoに慣れてくしかないですよね。

「Laravelってよくできたフレームワークだったんだなぁ」と改めて実感しました。

まぁ「住めば都」と言う話なんでしょうけど。