プロジェクト構成
Djangoのプロジェクト構成
Djangoでプロジェクトを作成すると自動でいくつかのフォルダとファイルが作成され、同ディレクトリに配置されます。
例えば、sample_appという名前でプロジェクトを作成すると初め以下のようなファイルが作成されます。
sample_app
- sample_app
- sample_app
- init.py
- asgi.py
- settings.py
- urls.py
- wsgi.py
- manage.py
アプリケーションの追加
基本的には、プロジェクトの作成後、アプリケーションを追加していきます。
ここでは、accountとfunctionというアプリケーションを追加したと仮定しましょう。
２つのフォルダとファイルが自動で作成されプロジェクトフォルダは以下のようになります。
sample_app
- account
- __init__.py
- admin.py
- apps.py
- models.py
- tests.py
- views.py
- function
- __init__.py
- admin.py
- apps.py
- models.py
- tests.py
- views.py
- sample_app
- __init__.py
- asgi.py
- settings.py
- urls.py
- wsgi.py
- manage.py
configフォルダ
プロジェクトを作成した時に作成されるフォルダをここではconfigディレクトリと呼びましょう。基本的にはこのフォルダ名はプロジェクト名と同じ名前が適用されます。
まずはこのフォルダ内のファイルとmanage.py について触れていきましょう。
-
sample_app/__init__.py
Python関連のパッケージをインポートする際に読み込まれる初期化用ファイル。 *このファイルは触ることがほぼないので無視で大丈夫です。 -
sample_app/asgi.py
Django3から登場したファイルです。Djangoにリアルタイムな双方向通信機能を持たしてデプロイ/稼働する際に必要となります。こちらも基本的なユースケースでは必要になることはありません。 -
sample_app/settings.py
プロジェクトのディレクトリ指定や各ファイルの指定、その他プロジェクトに関する全ての設定がここで記述されます。実際に記述する内容は多いので少しづつ必要なところから覚えていけると良いと思います。 -
sample_app/urls.py
プロジェクトのルーティングを設定するのに必要なファイルです。各appにそれぞれurls.pyを手動で追加し、それらのurls.pyをこのconfigフォルダ内のurls.pyに読み込んでプロジェクト全体のルーティングを記述するのが一般的です。書き方はほぼ定型なので一度覚えてしまうと簡単です。 -
sample_app/wsgi.py
基本的にDjangoをデプロイ/稼働する際に必要となるファイルです。何か記述するものがあるわけではありませんのでこちらも学習段階では無視で大丈夫です。 -
manage.py
Djangoの全てのプログラムがこのmanage.pyをトリガーとして行われます。そのためappを追加する際やDBを更新する際などには必ずpython manage.pyという記述を行います。
appフォルダ
appを追加すると自動でそのappの名前を持ったディレクトリが自動作成されます。自動作成されるファイルについて触れていきましょう。
-
*/__init__.py
上述の__init__.pyと同じ役割です。 こちらは無視で大丈夫です。 -
*/admin.py
Djangoにはプロジェクトの作成と同時に自動でデータの管理画面が作成されます。この管理画面で表示するデータの設定や機能の追加などをここで行います。ここは管理者画面の立ち位置なので、会員登録機能などで作られるユーザーでは入ることができず、スタッフ権限を持ったユーザーのみがログインして閲覧することができます。 -
*/apps.py
ここにはappの設定を記述することでその内容をconfigフォルダのsettings.pyで読み込めるようにし、結果的にプロジェクト全体に、該当するappの機能を反映しています。デフォルトですでに必要なコードが記述されてあるのでこちらもほぼ触れることはありません。 -
*/models.py 重要
前章のMTVフレームワークで触れたM（モデル）の部分であり、DBに登録するテーブルを記述していきます。基本的にはClassベースで記述していき、最終的にmigrateというアクションでデータ構造をデータベースに登録します。 -
*/tests.py
Djangoのもつユニットテスト機能をこのtests.pyを使用して行うことができます。初めはあまりテストを意識することはないと思うので触れる機会は少ないかもしれませんが、開発を進めていくにつれてこの記述を行っていくことになるでしょう。ここでは開発で使用しているデータベースとは別にダミーのデータベースを立てることができ、それを使用して自分の作った機能がうまく動くかテストすることができます。 -
*/views.py 重要
前章のMTVフレームワークで触れたV（ビュー）の部分であり、Djangoプロジェクトの中核を担います。主にバックエンドとなるファイルです。このファイルにmodels.pyからClassを読み込んだり、各種パッケージ機能などを読み込んだりしながらhtmlファイルの設定や投げるデータの登録、バックエンドとしての機能を持たせることができます。このファイルを使用することが一番多いでしょう。 -
（任意）*/urls.py
一般的なDjangoの開発手法では、自分でurls.pyをappフォルダ内に作成することが多いです。ここにviews.pyで作成したClassまたは関数を読み込んでapp内のルーティングを登録します。
基本的には上述したファイル群がappを追加するごとに作成されます。
プロジェクト内で機能ごとにappを分けることが多いので、大まかな機能の領域ごとにappが存在することになります。例えば、アカウント機能、サービスの主要機能、通知機能となれば3つのappを追加することになり、その数だけ上述したファイルが作られることになります。
その他のフォルダ
configフォルダとappフォルダ以外にもstaticフォルダとtemplatesフォルダを作成することがあります。Djangoの慣習に従うと、フロントエンドを記述するために各appフォルダにさらにstaticフォルダとtemplatesフォルダを作成し、staticの中にcssやjsファイル、templatesの中にhtmlファイルを作成することが書かれていますが、実際に開発現場となるとこれらのフォルダをconfigフォルダやappフォルダと同じ階層に置くことが多いです。
少しsettings.pyをいじることで、staticとtemplatesフォルダをプロジェクトの階層に作り、全てのフロントエンド関連のファイルをまとめて置くことができます。
そうなった場合、configフォルダとappフォルダの他にも staticフォルダとtemplatesフォルダがプロジェクト内に設置されます。
最後に
フォルダ構成やそれぞれの役割は実際に開発を進めていくと嫌でも知っていくことになると思います。
あらかじめ大まかに覚えておくと、Webフレームワークのブラックボックス化を防ぐことができるのでぜひ覚えておきましょう！
Just Python フリープラン
ジャスパイなら教材は全て無料！