Laravel 使いが Django を触って混乱したパートについて その2

Laravel 使いが Django を触って混乱したパートについて その2

参考図書片手に作業を行い感じていた「結局そのパートは何するのさ」についてまとめてみたいと思います。
コマンドでプロジェクトを作成するとこんな構成が自動生成されます。

Laravelerな私には見慣れた文字もちらほら。

同じ名前だからといって使い方が同じとは限らない

混乱の一端は Laravel と Django 共に使われる【views/models】という単語とLaravelには出てこない【admin/apps/forms/urls】といった面々。そして【migration】の感覚の違いでした。

特にviewsの認識がLaravelとは大きく異なる点には注意が必要です。
Djangoのviews.pyってLaravelのControllerとニアイコールですから。

【project\urls.py】【app\urls.py】って結局なに？

project\urls.py は app\urls.pyをIncludeする場所と思っていて問題ない様です。
Laravel流だと【routes\web.php】に全てのurlルートが記載される形になると思いますが、Djangoではこれを2パーツに分類して登録します。

アプリごとにまとめて親であるproject\urls.pyにIncludeさせることでお互いが見やすくなっています。

app\urls.pyが Laravelのroutes\web.phpに（書き方も含め）近いです。

views.pyって結局なに？

Laravelで言う所のControllerというのが最も近い認識だと思います。
viewと言う名前にダマされて違和感を覚えていたけどControllerだと思えばヤッテル事は確かに一緒でした。

こんな事を指示しています。※Controllerなので統括するproject\views.pyは存在しない。

でも、Laravelと大きく違いそうなところが『SQL文の記載』について。
DjangoではModelsでの記載が標準的の様です。
※Viewsでも書けるみたいだけど、MODELでクラス名付けて抽出計算までしてしまって、それをViewに渡すと言うスタイルをとるのが定番の姿らしい。

Laravelでもモデル内でクラス分けして書く事も出来るけど、抽出ワードとかがView（テンプレート）からControllerに来るからModelに渡さずにControllerで処理する事が多いのが現実です。

ちなみに、DjangoにもEloquentのようなSQLの独自な記載方法がありました。
Django版のEloquentは【QuerySetAPI】と言うらしいです。
Eloquentと書き方はだいぶ違うのでちょっと困るけど、記事も豊富なので何とかなりそうかな。

apps.pyって結局なに？

公式調べてみたらこんな事が書いてありました。うん、意味不明。

動作を追えば、ファイル内にコンフィグとして用意して Projectのsettings.pyの INSTALLED_APPSに記載するのは分かるのですが「で、それは何なの？」と言う所が今一つピンときませんでした。
Laravelってここら辺の動作全て自動だしね。

これ、全体のディレクトリ構成を考えてみてやりたい事が理解できました。
Laravelとは違って Djangoプロジェクトはアプリの寄せ集めと言う体を取っています。
その為「きっと【アプリの取り外し】という概念が必要だったのだろう」と勝手に解釈しました。

実際、このスタイルが便利なのは【アプリごとの課金】等の時。
アプリのON/OFFをsettings.pyで調整できますからね。
状況に合わせて読み込むsetting.pyを変えれば、アプリの利用制限を簡単にcontrolできます。
というか、今現状でそれ以外の使い方が見つけられない。

admin.pyって結局なに？

こいつはどうやらDjango管理画面を構成する要素の1つらしいです。
と言う事は、定型書いて終わりでいいファイル…でいいのかな。

他にもあるのかもしれないけど、今のところの理解はそんな感じ。

makemigrationとmigrationの違いはなに？

そもそもDjangoでマイグレーションファイルを作成した覚えがないのにマイグレーションしろと参考図書に指示がありました。で言われるまま操作したらマイグレーションが成功したと。

Laravel書いてるとき確かにに思ってました。
「マイグレーション書くのメンドクね？」
で最終的には「直接SQLにログインして書くからマイグレーション要らねーや」

それくらい全てのテーブルの項目を追うって作業は『発想しながら作る』場合には超ネックでした。
だって、テーブル構成変わったりするしね。

ただ、Djangoさんはそんなことを許さないのです。
何故なら、models.py にカラムの構成書かなきゃいけないんだもん。
「でも2重に書かなくてもいいからね」と言うのが【makemigration】で、そこから本当にCreateSQLを発行するのがmigrationと覚えました。

__init__.pyって結局なに？

これが今現在で一番理解できていないとおもいます。

色々調べてみるとアプリ内のインデックス的役割の様だけど。

Laravelで言う所の resources\views はどこへ行ったか

この機能について、Djangoの中ではテンプレートと呼びます。

アプリ内にtemplatesディレクトリを作成し、その中に拡張子htmlで書き進んでいくのがスタイル。
でも、Laravelのblade同様に小分けにして読み込ませることも親の形式を利用して当て込む事も出来ます。
Laravelでは【@】で始めたループ等の処理は{% %}で同じように開始可能。終了マーカーが必要なのも同じ。
objectや配列の値を記載する際にはLaravelと同じく【{{ }}】で囲って記載します。

Laravel目線で書くとこうなんですけど…混乱しますね。

まとめ

今回の一番の混乱はviewsという共通で使われるキーワードが行う仕事の違い。
よく知ってるフレームワークがある事で理解に苦しむところもありますけど比較してみるとやはり覚えやすいみたいです。