このページでは Django の全体像やファイル構成、さらには動作の仕組みについて解説していきたいと思います。特に Django 初心者の方向けの解説となります。
下記ページで解説しているように、Django はウェブアプリケーションフレームワークの１つであり、Django の利用により効率的なウェブアプリ開発を実現することができます。
【Django入門１】Djangoとは？
こういったメリットもある一方で、Django は慣れるまでが大変であるというデメリットもあり、ある程度 Django に慣れるまではむしろ「開発しにくい」と感じることも多いと思います。
そこで、このページでは、Django に慣れるための知識として Django の全体像や動作の仕組みについて解説をしていきたいと思います。
もちろん、Django は大量の Python スクリプトから構成され、さらに多種多様な機能を提供するフレームワークですので、このページのみで Django 全てについて語り尽くすことはできません。ただ、このページを読むことで Django の全体像がボヤッとでも掴むことができ、Django での開発時に「何をやっているか分からない…」という状態は脱却できるようになるのではないかと思います。
是非最後まで読んでみてください！
Contents
Django の全体像
では、Django の全体像について解説していきます。
Django = ウェブアプリフレームワーク
まず、Django はウェブアプリフレームワークの１つになります。
こういったフレームワークを利用することで、ウェブアプリを効率的に開発することができるようになります。フレームワークがどういったものであるかや、フレームワークを利用することでアプリ開発が効率的になる理由などは下記で解説していますので、詳しく知りたい方は下記ページを参照していただければと思います。
【Django入門１】Djangoとは？
スポンサーリンク
ウェブアプリとは
では、ウェブアプリとは何でしょうか？
ウェブアプリとは簡単に言えば「リクエストを受け取り、そのリクエストに応じた機能を実行し、その機能から得られた結果に応じたレスポンスを返却するアプリ」のことを言います。
リクエストを送信するのはクライアントであり、ユーザーがクライアントを操作してリクエストを送信することで、ユーザーがウェブアプリの機能を利用することができることになります。このクライアントの代表例はウェブブラウザになります。
また、ウェブアプリでは、リクエストやレスポンスの送受信は HTTP での通信によって行われることになります。なので、リクエストは「HTTP リクエスト」、レスポンスは「HTTP レスポンス」と呼ぶのが正確なのですが、このページでは単にリクエスト・レスポンスと記していきます。
Django で開発したウェブアプリの場合、上の図のように直接ウェブアプリがクライアントとデータのやり取りを行うのではなく、他のソフトウェアを経由してクライアントとウェブアプリの間でデータのやり取りが行われることになります
これについては後述で解説します
ウェブアプリの機能とリクエスト
このリクエストの内容やレスポンスの内容はウェブアプリによって異なります。また、通常ウェブアプリで受け付け可能なリクエストの種類は複数存在します。基本的には、ウェブアプリで「リクエスト」と「機能」とは一対一で対応することになり、受け付けたリクエストに応じた機能が動作することになります。
例えば Twitter は「ツイート一覧取得機能」を備えたウェブアプリです。そして、Twitter は「特定のユーザーのツイート一覧を取得したい」というリクエストを受け付け可能になっています。このリクエストを受け付けたウェブアプリは「特定のユーザーのツイート一覧」をデータベースから取得し、その結果をレスポンスとして返却することで、クライアントはユーザーのツイート履歴一覧を得ることができるようになっています。
つまり、Twitter の「ツイート一覧取得機能」は「特定のユーザーのツイート一覧を取得したい」というリクエストを送信することで利用可能ということになります。Twitter の場合は他にもたくさんの機能が存在し、それらの機能を利用するためのリクエストが存在します。例えば「いいね！」ボタンをクリックしたときにもリクエストが送信されることで Twitter の機能が動作していることになります。
こんな感じで、ユーザーがウェブアプリの機能が利用できるのは、クライアントからウェブアプリに対してリクエストが送信されているからになります。ボタンのクリック等でウェブアプリを操作しているように感じる時もありますが、実は裏ではリクエストの送信とレスポンスの受信が行われています。
このようにリクエストの送信によって機能の利用を要求することができる点はウェブアプリの特徴であると言って良いと思います。
ウェブアプリの機能とデータベース
また、上記の例も当てはまるのですが、ウェブアプリに備えられる機能にはデータベースに関連するものが多いです。
Twitter の場合はユーザーの情報やツイートがデータベースに保存されるようになっており、データベースへの新規ツイートの保存により「ツイート投稿機能」が実現できるようになっていますし、データベースからの特定のユーザーのツイート一覧を取得することで「ツイート一覧取得機能」が実現できるようになっています。
基本的には、ウェブアプリでデータを保存する際にはデータベースを利用すると考えて良いと思います。
また、データベースで管理するデータはウェブアプリによって異なります。データベースで管理するデータがウェブアプリの機能に大きく関わることになるため、より魅力的なウェブアプリの機能を実現するためにデータベースで管理すべきデータをしっかり検討する必要があります。
ウェブアプリの機能とレスポンス
そして、この “機能から得られた結果” はリクエストに対するレスポンスとして返却されてクライアントが受け取ることになります。前述のとおり、ウェブアプリの機能はデータベースの操作によって実現されるものが多く、データベースの操作結果 (成功 or 失敗 or 取得したデータ等) をレスポンスとして返却することが多いです。特にウェブアプリがウェブブラウザから利用される場合は、データベースの操作結果を埋め込んだ HTML がレスポンスとして返却されることになります。
こんな感じで、「リクエストを受け取り、そのリクエストに応じた機能を実行し、その機能から得られた結果に応じたレスポンスを返却するアプリ」がウェブアプリです。
そして、前述のとおり、ウェブアプリの機能はリクエストの送信によって実行されます。また、ウェブアプリの機能はデータベースへの操作によって実現されることが多いです。さらに、ウェブアプリのレスポンスは HTML データであることが多いです。
なので、ウェブアプリの開発では、機能を単に考えるだけでなく下記のようなことを検討し、これらを実装していく必要があります。
- ①：機能そのもの
- ②：機能の利用を要求するためのリクエストの内容
- ③：機能を実現するために必要となるデータベースで管理するデータ
- ④：機能のレスポンスの内容（HTML の構成など）
詳細については後述で説明しますが、Django で開発するウェブアプリを構成するファイルにおいて、①の実装先は views.py、②の実装先は urls.py、③の実装先は models.py、④の実装先は templates 以下のファイルとなります。
ここを頭に入れておくと、今後の説明が理解しやすくなると思いますので、上記の内容は頭の片隅にでも置いておいてください。
ウェブアプリが動作する環境・ウェブアプリの動作の流れ
Django の詳細を解説する前に、次はウェブアプリが動作する環境や、ウェブアプリの動作の流れについて説明しておきます。
ウェブアプリが動作する環境
ウェブアプリはウェブブラウザ等のクライアントから利用可能なアプリであり、サーバーマシン上からウェブアプリを公開することが一般的です。ウェブアプリがユーザーのウェブブラウザから利用される際のサーバーマシン上のソフトウェアの構成例は下の図のようになります。
基本的に、Django での開発対象となるのは、下の図における “ウェブアプリ” 部分のみとなります。ウェブサーバーや AP サーバーには他の OSS が利用されることが多いです。特に Django 入門者の方は、これらのウェブサーバーや AP サーバーについて深く理解する必要もないですが、ウェブアプリが他の上位のサーバーからリクエストを受け取って動作することは覚えておきましょう！
以降では、ウェブアプリが利用される際の、ウェブサーバー・AP サーバー・そしてウェブアプリの動作の流れを簡単に説明していきます。
一点補足しておくと、上の図ではウェブブラウザがウェブアプリを利用する例を示していますが、ウェブアプリは専用のアプリ（スマホアプリ等）から利用されることも多いです。例えば Twitter や Facebook などは専用のスマホアプリから利用可能ですよね。もちろん、Django で開発したウェブアプリも、自身で専用のスマホアプリを開発すれば、そのアプリから利用することは可能です。ですが、最初はウェブブラウザから利用することを前提に学習していった方が分かりやすいと思いますので、このサイトでは、ウェブアプリはウェブブラウザから利用されることを前提に解説を進めていきたいと思います。
ウェブサーバーがリクエストを受け取る
まず、ユーザーはウェブアプリの機能を利用するためにリクエストの送信を行う必要があります。このリクエストは、ウェブブラウザのアドレスバーに URL を指定したり、リンク先の URL が指定されたリンクテキストをクリックしたりすることで送信できます。
これらの操作によって送信されるリクエストは、厳密には HTTP リクエストと呼ばれ、下図のような構成のデータとなります。ポイントになるのが破線で囲っている部分で、青の破線部分は “メソッド”、オレンジの破線部分は “URL” となります。ちなみに、リクエストのデータの URL はルートパス指定（ドメイン名などを省略した URL の指定方法）で記述されることが多いです。
ポイントは、メソッドと URL の２つで「利用したいウェブアプリの機能」が指定されるという点になります。したがって、ウェブアプリは、リクエストを受け取った際には、メソッドと URL に応じた機能を実行する必要があります。
また、これらの操作によってウェブブラウザ等のクライアントから送信されたリクエストはウェブサーバーが受け取ることになります。
例えば、ウェブブラウザのアドレスバーに http://daeudaeu.com/users/ という URL を指定した場合、daeudaeu.com のドメイン名に対応するサーバーマシンで動作しているウェブサーバーにリクエストが送信されることになります。そして、ウェブサーバーが受け取るリクエストのメソッド・URL は下図のようなものになります。このように、リクエストの送信先に関しては URL のドメイン名で決まります。そして、ルートパス指定の URL がリクエストのデータに指定されることになります。また、ウェブブラウザのアドレスバーに URL を指定した場合は、（おそらく）必ずメソッドは GET となります。
ウェブアプリがリクエストに応じた機能を実行する
そして、ウェブサーバーから AP サーバーを経由してウェブアプリがリクエストを受け取ることになります。そして、このウェブアプリがリクエストに応じた機能を実行することになります。この時に実行される機能は、前述で説明したようにメソッドと URL に基づいて決定されます。
例えば、ウェブブラウザのアドレスバーに http://daeudaeu.com/users/ という URL が指定された場合、ウェブサーバー等を介してウェブアプリにリクエストが渡され、ウェブアプリは、メソッド (GET) と URL (/users/) に対応した機能を実行することになります。
例えば、GET /users/ のリクエストが「ウェブアプリ利用者一覧の取得」機能の利用を要求するものであれば、ウェブアプリはデータベースからウェブアプリの利用者一覧のデータを取得するような処理を実行することになります。
こんな感じで、ウェブアプリは受け取ったリクエストのメソッドと URL に応じた機能を実行します。
ウェブサーバーがレスポンスを返却する
さらに、機能の実行結果に基づいたレスポンスをウェブアプリが AP サーバーに返却することになります。そして、AP サーバーからウェブサーバーにレスポンスが返却され、そのレスポンスをウェブサーバーがクライアント（ウェブブラウザ）に対して返却することになります。
これにより、ウェブブラウザがレスポンスを受け取り、そのレスポンスに基づいたページの描画が行われます。例えば、GET /users/ のリクエストが「ウェブアプリ利用者一覧の取得」機能の利用を要求するものであれば、ウェブアプリ利用者一覧を含む HTML がウェブアプリからレスポンスとして返却され、それを受け取ったクライアントが、その HTML に基づいてページを描画することになります。そして、ユーザーが、そのページからウェブアプリ利用者一覧を確認することが出来ることになります。
こここまでの説明のとおり、ウェブアプリでは、上位のサーバーから受け取ったリクエストに応じた機能・処理を実行し、その結果をレスポンスとして返却することが重要となります。クライアントから送信されてくるリクエストは、機能の利用を要求するデータなので、これを無視してウェブアプリ動作するとクライアントの要求が満たされないことになります。クライアントの要求を満たすためには、リクエストに応じた機能・処理を実行し、その結果をレスポンスとして返却する流れが必要となります。
メソッドと URL についての補足
ここで、リクエストに含まれるメソッドと URL について補足しておきます。
前述のとおり、メソッドと URL は「利用したい機能」を指定するデータとなります。そして、このメソッドとして指定可能な文字列としては下記のようなものが挙げられます。他にもさまざまな種類のメソッドが存在するのですが、まずは下記の３つ、特に GET と POST を覚えておくとよいと思います。
GET: データの取得POST: データの新規作成・データの送信DELETE: データの削除
これらのメソッドは、ウェブアプリを利用して「どうしたいのか？」という “リクエストの目的” を伝えるデータとなります。それに対して URL は 「何に対するリクエストなのか？」という “リクエスト対象のリソース” を伝えるデータとなります。そして、メソッドと URL を組み合わせることによって「何をどうしたいのか？」という “利用したい機能” を伝えるためのデータとなります。
例えば、/comment/ という URL がコメントというリソースを示すのであれば、GET /comment/ のリクエストは「コメントを取得したい」となり、このリクエストを受け取ったウェブアプリは、そのリクエストに応えるために「コメント取得機能 」を実行する必要があります。それに対し、POST /comment/ のリクエストは「コメントを新規作成したい」となり、このリクエストを受け取ったウェブアプリは、そのリクエストに応えるために「コメント投稿機能」を実行する必要があります。
こんな感じで、リクエストのメソッドと URL で「何をどうしたいのか？」というクライアント（ユーザー）の要求が伝えられることになるため、ここまでの説明のとおり、ウェブアプリは、その要求に対応した機能を実行する必要があります。
開発用ウェブサーバーでのウェブアプリの動作確認
さて、ここまではウェブアプリが下の図のようなソフトウェアの構成の中で動作すると説明してきました。ただ、これはウェブアプリ公開後のソフトウェアの構成となります。つまり、Django でのウェブアプリ開発中の動作確認では、下図とは異なる構成でウェブアプリを動作させることになります。
具体的には、Django でのウェブアプリ開発時には、Django から提供される「開発用ウェブサーバー」を利用してウェブアプリを動作させることになります。次は、この開発用ウェブサーバーについて簡単に紹介しておきます。
開発用ウェブサーバーとは
前述の通り、ウェブアプリは他のサーバーから実行されることで動作することになります。前述では AP サーバーからウェブアプリが実行される構成を紹介しましたね！
ただ、ウェブアプリの公開時に他のサーバーを用意するのは仕方ないとしても、お試しでのウェブアプリの実行や、開発時の動作確認ためにわざわざ他のサーバーを用意するのは面倒です。
この面倒さを解消するため、Django では開発用ウェブサーバーが用意されており、これが前述のウェブサーバーや AP サーバー等の代わりとなるようになっています。したがって、動作確認のためにウェブアプリを動作させるのに他のサーバーをわざわざ用意する必要がなく、Django さえインストールしておけば開発用ウェブサーバーを利用してウェブアプリを動作させることができます。
開発用ウェブサーバー利用時のソフトウェア構成
この開発用ウェブサーバーを利用した時の構成は下の図のようになります（開発用ウェブサーバーは Django フレームワークの一部と言っても良いかもしれませんが、このページではこれらを別のものとして扱って説明していきたいと思います）。
ウェブアプリの動作確認時には、リクエストの送信やレスポンスの受信を行うクライアント（ウェブブラウザ等）も同じ PC 上で動作させることが多いため、上の図のように１つの PC 上で動作する構成を示しています。
開発用ウェブサーバーを利用する構成においては、ウェブブラウザ等のクライアントからの「リクエストの受信」やクライアントへの「レスポンスの返却」に関しては開発用ウェブサーバーの役割となります。リクエストを受け取った際には、開発用サーバーはウェブアプリを実行し、この際にウェブアプリへリクエストを渡します。そして、ウェブアプリから返却されたレスポンスをウェブブラウザ等のクライアントに返却してくれます。
そのため、Django では開発用ウェブサーバーの起動をしておくだけで「開発中のウェブアプリの動作確認」を行うことができることになります。基本的には、Django を利用したウェブアプリ開発においては、上図に示すような開発用ウェブサーバーを利用した構成で開発を行なっていくことになります。
ただし、開発用ウェブサーバーは、あくまでも Django で開発するウェブアプリの動作確認用に利用されるサーバーであり、ウェブアプリ公開時には利用されません。そのため、ウェブアプリが完成して公開する際には、ウェブアプリが動作する環境・ウェブアプリの動作の流れ で示したようなウェブサーバーや AP サーバー等を利用する構成（本番環境）に移行する必要があります。
スポンサーリンク
Django で開発するウェブアプリ内部の構成
ここまでは、他のソフトウェアとの関係性を示す形でウェブアプリの全体像を解説してきました。
ここからは、ウェブアプリに注目し、Django で開発するウェブアプリ内部の構成について説明していきたいと思います。
ウェブアプリの構成
Django で開発するウェブアプリの構成を簡単に示したものが下図となります。
Django を利用して開発するウェブアプリは大きく２つの部分から構成されます。１つ目はフレームワーク、つまり Django であり、２つ目はプロジェクトになります。１つ目の部分は単に Django と記しても良いかもしれませんが、フレームワークであることを意識していただきたいため、Django フレームワークと記していきたいと思います。
この２つは役割が大きく異なり、Django フレームワークの役割は「ウェブアプリで共通的な機能を提供する」ことであり、プロジェクトの役割は「開発するウェブアプリ特有の機能を提供する」ことになります。
Django フレームワーク
前者の Django フレームワークは、下記ページでも解説しているとおり、ウェブアプリにおける共通的な機能や構造を提供する枠組みとなります。
【Django入門１】Djangoとは？
ここまで説明してきた通り、ウェブアプリではリクエストを受け付ける機能が必ず必要になります。またデータベース操作機能が必要となる場合も多いです。他にもログイン等を実現するために認証機能を備えているウェブアプリが多いです。こういったウェブアプリで一般的に共通して利用される機能が Django フレームワークから提供されるようになっています（下図では共通的な機能を青四角で４つのみ記載していますが、他にも多くの機能が存在します）。
つまり、Django フレームワークの機能を利用するだけで、上記のようなウェブアプリで共通となる処理や動作を実現することができます。この Django フレームワークは Django をインストールすることで自動的に PC 内に構築され、Django で開発するウェブアプリにおいて共通的に利用されるものになります。
プロジェクト
Django フレームワークがウェブアプリで共通的な機能を提供するのに対し、プロジェクトは、そのウェブアプリ特有の機能を提供する部分になります。Django を利用する場合、開発者の主な開発対象は、このプロジェクトのみとなります。Django フレームワークに関しては、そのまま利用します。
このプロジェクトで主に行うことは、そのウェブアプリ特有の機能の実装となります。この機能を充実させていくことで、他のウェブアプリにはない特徴を生み出したり、他のウェブアプリよりも使いやすいウェブアプリを実現したりすることができます。要は、このプロジェクトを作りこんでいくことで他のウェブアプリとの差別化を図っていくことになります。そして、Django では、基本的にプロジェクト内の開発のみを行うため、Django を利用すれば、他のウェブアプリとの差別化に注力することができることになります。
また、ウェブアプリで共通的に必要となる Django フレームワークの機能は、プロジェクト内のファイルからも利用することが可能です。ですので、例えばプロジェクト内のファイルにデータベース操作の処理を自身で実装しなくても、Django のフレームワークの機能を利用するように実装するだけで、データベース操作を実現することができます。Django では、こういった Django フレームワークの機能も利用しながら効率的にプロジェクトを開発していくことが可能です。
ただし、Django フレームワークの使い方（例えば Django フレームワークの関数を実行する順番や実行時に渡す引数など）に関しては、開発者自身が開発対象のウェブアプリに合わせて考える必要があります。
逆に、プロジェクト内のファイルや、それらのファイルで定義した関数が Django フレームワークから利用されることもあります。そのため、これらは Django フレームワークが期待する構成で作成していく必要があります。
Django フレームワークとプロジェクトにおけるファイル位置の関係
ここで１点補足しておくと、ウェブアプリの構成が下の図のようになると考えられるのは「動作的な構成」で考えた場合となります。
実際には、Django フレームワークとプロジェクトのファイルは別々の場所にあるので注意してください。
Django フレームワークを構成するファイルは Django 自体のインストール先のフォルダ内に存在します。この Django フレームワークが存在する位置に関しては環境等によって異なるので一概には言えないのですが、例えば私の環境であれば下記フォルダ以下に Django フレームワークを構成するファイルが存在しています。
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/django
それに対し、プロジェクトのファイルは、後述の Django のプロジェクトの作り方・ウェブアプリの動かし方 で紹介するコマンドによって自動的に生成されるもので、好きな場所に作成することができます。例えばドキュメントフォルダの下やデスクトップに作成することが多いと思います。
つまり、Django フレームワークとプロジェクトのファイルは全く別々の場所に存在することになります。
ですが、動作的に考えると、プロジェクト内のファイルから Django フレームワーク内のファイルで定義される関数を実行したり、逆に Django フレームワーク内のファイルからプロジェクト内のファイルで定義された関数が実行されたりするため、先ほど示した Django フレームワークがプロジェクトを囲う形の構成がしっくりくるのではないかと思います。
Django のプロジェクトの構成
さて、先ほど Django で開発するウェブアプリは Django フレームワークとプロジェクトの２つから構成されると説明しました。
前者の Django フレームワークに関しては、基本的にインストールされたものをそのまま利用することになり、開発者は主に、後者のプロジェクト内のファイルを編集していくことでウェブアプリを開発していくことになります。
基本的に Django フレームワークを直接変更することはありませんが、プロジェクト内のファイルによって Django フレームワークの動作の設定を行うことが可能です
これの詳細に関しては、後述の Django のプロジェクトの作り方・ウェブアプリの動かし方 で解説します
次は、このプロジェクトに焦点を当て、プロジェクトを構成するファイル・フォルダの構成および、各ファイルの役割について解説していきます。
プロジェクト内のファイル
Django において、プロジェクトの実体はフォルダとなります。
プロジェクトを構成するファイル・フォルダ
そして、このプロジェクト内には下図のようなファイルやフォルダが存在します（__init__.py は省略しています）。プロジェクトの中に「プロジェクト名 フォルダ」があってややこしいので、以降では、プロジェクトの内側に存在する「プロジェクト名 フォルダ」のことを プロジェクト設定フォルダ と呼ばせていただきます。
Django を利用したウェブアプリ開発では、主にこれらのファイルを変更することでウェブアプリを開発していくことになります。また、これらのファイルやフォルダは、基本的には後述の Django のプロジェクトの作り方・ウェブアプリの動かし方 で紹介するコマンドを実行することで自動的に生成されるものになりますが、一部のピンク色の文字で示したファイルやフォルダに関しては自動生成されないため、開発者自身が手動で作成する必要があります。
各ファイル・各フォルダの役割
上の図で示す各フォルダ・各ファイルの役割を簡単に記すと下記のようになります。
manage.py：Django 向けのコマンドを実行するスクリプトファイル★プロジェクト設定フォルダ：プロジェクトの設定ファイルを格納するフォルダ__init__.py：Python にプロジェクト名フォルダをパッケージとして認識させるためのファイルsettings.py：Django フレームワークの動作を設定するファイル★urls.py：URL とアプリとの対応付けを定義するファイルwsgi.py：サーバーとのインターフェースを定義するファイル（WSGI 用）asgi.py：サーバーとのインターフェースを定義するファイル（ASGI 用）
アプリ名フォルダ：アプリを構成するファイルを格納するフォルダ__init__.py：Python にアプリ名フォルダをパッケージとして認識させるためのファイルapps.py：アプリ独自の設定ファイルviews.py：アプリの機能を実装するファイル（MTV の View）models.py：データベースで管理するデータの定義・データベース操作を実装するファイル（MTV における Model ）forms.py：データの送信フォームを実装するファイルadmin.py：管理画面用の設定ファイルtests.py：テスト用のファイルurls.py：URL と関数との対応付けを定義するファイルmigration フォルダ：マイグレーションの設定ファイルを格納するフォルダ__init__.py：Python にmigrationsフォルダをパッケージとして認識させるためのファイル
templates フォルダ：HTML のテンプレートファイルを提供するフォルダ（MTV における Templat）xxx.html等：テンプレートファイル（複数のファイル用意）
たくさんのファイルが存在しますが、この中で特に重要になるのが太字で示した views.py、models.py、templates フォルダ以下 のファイル、そして urls.py となります。これらはウェブアプリの機能を実現していく上で変更・作成が必要となるファイル群となります。これらのファイルについては、後述の ウェブアプリの機能を実現するファイル で詳細を説明していきます。
また、ウェブアプリを開発する・ウェブアプリを動かすという観点では、★マークを付けた manage.py、settings.py の２つのファイルも重要となります。この２つに関しては、後述の Django のプロジェクトの作り方・ウェブアプリの動かし方 の中で説明をしたいと思います。
スポンサーリンク
プロジェクト・プロジェクト設定・アプリの関係
ここまでの説明のように、プロジェクトはフォルダであり、そのフォルダ内に プロジェクト設定フォルダ と アプリフォルダ が存在することになります。ここで、これらのフォルダの関係性について解説しておきます。
プロジェクト：プロジェクト設定とアプリをまとめたフォルダ
まず「プロジェクト」はウェブアプリの一部になります。Django フレームワークと連携して動作させることでウェブアプリが実現できることになります。そして、このプロジェクトは１つの プロジェクト設定フォルダ と１つ or 複数の アプリフォルダ から構成されます。
アプリ：ウェブアプリ特有の機能を実現するフォルダ
続いて アプリフォルダ について説明すると、アプリフォルダ は開発するウェブアプリ特有の動作や機能を実現していくためのフォルダとなります。このフォルダ内に MTV モデルを形成するファイルが存在し、これらを作りこんでいくことで世界で一つだけのウェブアプリを開発することが出来ます。
この アプリフォルダ はプロジェクト内に複数存在させることもでき、１つの アプリフォルダ で１つのウェブアプリとして仕上げることもできますし、複数の アプリフォルダ 内のファイルを連携動作させることで１つのウェブアプリとして仕上げていくこともできます。
複数の アプリフォルダ から１つのウェブアプリを開発するメリットとしては「他のプロジェクトへの機能の流用が容易になる」が挙げられます。要は、他のプロジェクトへの機能の使い回しが楽に実現できます。例えば、ウェブアプリの機能のうち “ログイン機能のみ” を切り離して１つの アプリフォルダ として開発すれば、そのログイン機能の他のプロジェクトへの流用が容易になります。なぜなら、その流用は、その アプリフォルダ のコピーのみで実現できるからです。
逆に、ウェブアプリの全機能を１つの アプリフォルダ 内で実現してしまうと、機能の他のプロジェクトへの流用が大変になります。この場合、各種ソースコードから、その機能に関連する部分のみを全てをコピペするようなことが必要になって手間が多くなりますし、コピペの漏れなどがあるとバグが発生する可能性もあります。なので、他のウェブアプリ（プロジェクト）でも使うことがありそうな機能に関しては、他の機能とは分離して別の アプリフォルダ で開発することをオススメします。
プロジェクト設定：フレームワークの動作を設定するフォルダ
アプリフォルダ がウェブアプリ特有の機能を実現するフォルダであるのに対し、プロジェクト設定フォルダ は共通機能を提供する Django フレームワーク側の動作を設定するためのフォルダと考えて良いです。言い方を変えれば、プロジェクト内の「アプリ」共通の設定を行う部分とも言えます。Django フレームワーク自体を変更することは非推奨ですが、このプロジェクト設定フォルダ内のファイルを編集することで、Django フレームワークの動作を変化させることができます。
例えばですが、プロジェクト設定フォルダ の settings.py では使用するデータベースの設定を行うことができます。settings.py のデフォルト設定では使用するデータベースとして「SQLite3」が指定されていますが、settings.py を変更して使用するデータベースに「MySQL」を指定すれば、プロジェクト内の「アプリ」から Django フレームワークのデータベース操作機能を利用した際、データベース操作機能はデータベースとして MySQL を使用するようになります。
他にも、言語設定やタイムゾーンの設定等も settings.py によって変更可能です。
ただし、プロジェクト設定フォルダ はプロジェクト内の アプリフォルダ 全てに対する共通の設定となります。なので、Django フレームワークの機能の設定を アプリフォルダ ごとに変更したい場合は、それらの アプリフォルダ は別々の「プロジェクト」に分けて開発した方が良いと思います。
まずは、難しく考えずにプロジェクトの中には１つの アプリフォルダ のみを作成してウェブアプリを開発していくので良いと思います。ただし、アプリフォルダ はプロジェクト内に複数作成可能であること、また機能ごとに アプリフォルダ を設けることで機能のほかのプロジェクトへの流用が容易になることは覚えておきましょう！
ウェブアプリの機能を実現するファイル
続いて、特にウェブアプリの機能を実現していく上で重要となるファイルの説明を行っていきます。
ウェブアプリとは の節でウェブアプリの開発では下記を実装していく必要があると説明しました。そして、これらの実装先は、①が views.py、②が urls.py、③が models.py、④が templates フォルダ以下 のファイルとなります。そのため、Django でのウェブアプリの開発においては、これらの４つのファイルが重要となります。
- ①：機能そのもの
- ②：機能の利用を要求するためのリクエストの内容
- ③：機能を実現するために必要となるデータベースで管理するデータ
- ④：機能のレスポンスの内容（HTML の構成など）
特に、views.py、models.py、templates フォルダ以下のファイルに関しては、それぞれ下記ページでも解説している MTV モデルの View・Model・Template を実装していくファイルとなります。そして、Django を利用する場合、主に、この MTV を、つまり views.py、models.py、templates フォルダ以下 のファイルを作りこんでいくことでウェブアプリを開発していくことになります。なので、これらの３つのファイルは超重要なファイルとなります。
【Django入門１】Djangoとは？
もう１つ重要となるファイルが urls.py です。この urls.py では、ウェブアプリで受け付け可能な URL の定義と、それらの URL と関数との紐づけを行います。つまり、ウェブアプリでどんな URL のリクエストを受け付け、そのリクエストを受け取ったときに何を実行するのかを定義するファイルが urls.py となります。なので、この urls.py もウェブアプリの開発において重要なファイルとなります。この urls.py は プロジェクト名 フォルダと アプリ名 フォルダの２か所に存在しますが、これらの意味合いについても解説していきます。
urls.py
最初に urls.py について説明していきます。
urls.py の役割
urls.py は、ウェブアプリで受け付けるリクエストの URL の定義と、その URL を受け付けたときに実行する関数とのマッピング（対応付け）を行うファイルになります。このページでは、オブジェクトが関数であることを前提に解説を進めます。
ウェブアプリが動作する環境・ウェブアプリの動作の流れ でも説明したように、ウェブアプリでは受け取ったリクエストのメソッドと URL に応じた機能を実行する必要があります。また、これは後述でも解説しますが、この機能は views.py に関数（or クラス）として定義されることになります。これらの views.py の関数と、リクエストの URL とのマッピングを行うのが、ここで説明する urls.py の役割となります。ちなみに、メソッドに応じて実行する機能を切り替えるのは View (views.py) の役割になります。これについては views.py の節で解説します。
このマッピングを行っておくことで、特定の URL に対するリクエストをウェブアプリが受け取った時に、その URL にマッピングされた関数が自動的に実行されるようになります。
urls.py での URL と関数とのマッピング
この「URL と関数とのマッピング」は、urls.py で path 関数の返却値を要素とする urlpatterns というリストを定義することで実現できます。path 関数の第１引数には「ウェブアプリが受け付ける URL」を指定し、第２引数には「その URL のリクエストを受け取った時に実行する関数」を指定します。
イメージとしては、urls.py は下記のような構成となります。例えば下記であれば、URL が URL1・URL2・URL3 のリクエストをウェブアプリが受け取った場合に、それぞれ 関数1・関数2・関数3 が実行されることになります。
from django.urls import path
urlpatterns = [
path('URL1', 関数1),
path('URL2', 関数2),
path('URL3', 関数3),
]ウェブアプリが受け付ける URL の定義
この urls.py では、ウェブアプリが受け付け可能な URL を定義することも兼ねている点もポイントとなります。
つまり、関数とのマッピングを行った URL、すなわち path の第１引数に指定された URL のみがウェブアプリが受け付け可能な URL として定義されることになります。それ以外の URL は、ウェブアプリは受け付け不可となり、その URL を受け取った場合はエラーとなります（404 エラー）。
リクエストを受け取ったときに関数が実行される流れ
次は、リクエストを受け取った時に関数が実行される流れについて簡単に説明しておきたいと思います。これを理解しておけば urls.py の必要性も理解できると思います。
ウェブアプリが動作する環境・ウェブアプリの動作の流れ でも説明したように、ウェブアプリは他のサーバーソフトウェアからリクエストを受け取ることになります。このリクエストは Django フレームワークに渡され、そして、Django フレームワークがリクエストの URL に応じて実行する関数を決め、その関数を実際に実行することになります。
もっと正確に言うと、他のサーバーソフトウェアからのリクエストは、wsgi.py を介して Django フレームワークが受け取ることになります
この辺りに関しては Django のウェブアプリ内部の動作の流れ の章で簡単に説明します
なんですが、Django フレームワークは第三者が開発した全ウェブアプリでの共通部分です。なので、あなたが開発するウェブアプリがどんな URL を受け付け、その URL を受け取った時に何の関数を実行すれば良いのかを知りません。そのため、ウェブアプリが受け付け可能な URL と、それらの URL を受け取った時に実行する関数を、あなたが Django フレームワークに教えてあげる必要があります。
そして、それらを教えるためのファイルが urls.py になります。ウェブアプリが起動した際には、Django フレームワークから、この urls.py が読み込まれることになります。そして、この読み込みによって、そのウェブアプリが受け付ける URL と、その URL にマッピングされた機能を Django フレームワークが理解することになります。
そして、後は Django フレームワークがリクエストを受け取った時に、それに対応する関数を Django フレームワークが実行してくれるようになります。
逆に、urls.py が存在しないと、Django フレームワークは、ウェブアプリで受け付け可能な URL も、リクエストを受け取った時に実行すべき関数も分からなくなり、基本的には何もしないウェブアプリになってしまうことになります。
ということで、この urls.py は Django でのウェブアプリにおいて非常に重要なファイルとなります。
プロジェクトとアプリの urls.py
urls.py の解説の最後に、プロジェクト設定フォルダ の urls.py と アプリフォルダ の urls.py について解説しておきます。
urls.py は プロジェクト設定フォルダ と アプリフォルダ に存在します。今後は、前者を プロジェクト/urls.py、後者を アプリ/urls.py と呼ばせていただきます。
簡単に２つの urls.py の役割を説明すると、アプリ/urls.py は、そのアプリ内の関数と URL とのマッピングを行うことが役割で、プロジェクト/urls.py は、Django フレームワークに対し、アプリ/urls.py を読み込むように指示（設定）を行うことが役割となります。前述の説明で、Django フレームワークから urls.py が読み込まれると説明しましたが、この読み込み先のファイルはデフォルトでは プロジェクト/urls.py のみとなります。
ですが、プロジェクト/urls.py で Django フレームワークに対して アプリ/urls.py を読み込むように指示（設定）を行うことができ、これによって アプリ/urls.py も読み込ませることができるようになります。
このように プロジェクト/urls.py と アプリ/urls.py を作成することで、各 アプリフォルダ 内で実装する関数の URL へのマッピングも アプリフォルダ 内のファイルの編集のみで実現できるようになります。そして、これによって、プロジェクトとアプリ間の依存を減らし、他のプロジェクトへの機能の流用が容易になります。
プロジェクト/urls.py だけでなく アプリ/urls.py も設置する場合 、プロジェクト/urls.py は下記のように実装する必要があります。urlpatterns の１つ目の要素は自動生成時に記述されたものなので、まずは無視していただければと思います。この プロジェクト/urls.py のポイントは、基本的な構造に関しては前述で示した urls.py と同じなのですが、path の第２引数で機能となる関数等を指定するのではなく、include 関数を実行している点になります。
from django.contrib import admin
from django.urls import path, include
urlpatterns = [
path('admin/', admin.site.urls)
path('アプリ１を示す文字列/', include('アプリ１.urls'))
path('アプリ２を示す文字列/', include('アプリ２.urls'))
]このように、path の第２引数で include 関数を実行するようにすれば、第１引数で指定された文字列で始まる URL のリクエストを受け取った際には、include 関数の引数に指定した urls.py に従って URL と関数をマッピングするように Django フレームワークを設定することができます。具体的には、include 関数の引数に 'アプリ名.urls' を指定した場合、アプリ名 フォルダの下の urls.py、すなわち アプリ/urls.py が読み込まれ、その内容に従ってマッピングが行われることになります。
つまり、リクエストの URL が /アプリ１を示す文字列/ から始まる場合に アプリ１ フォルダの下の urls.py の内容に従って URL と関数とのマッピングが行われ、リクエストの URL が /アプリ２を示す文字列/ から始まる場合に アプリ２ フォルダの下の urls.py の内容に従って URL と関数とのマッピングが行われることになります。
そして、アプリ/urls.py の具体例は下記のようになります。こちらに関しては、今まで説明してきた通り、path 関数の第１引数には「ウェブアプリが受け付けるリクエストの URL」を指定し、第２引数には「その URL のリクエストを受け取ったときに実行する関数」を指定します。下記は、views.py に signup 関数と login 関数が定義されていることを前提とした例となっています。
from django.urls import path
from testapp import views
urlpatterns = [
path('signup/', views.signup),
path('login/', views.login),
]上記の アプリ/urls.py をアプリ１ フォルダの下の urls.pyとすれば、上記による URL と関数のマッピングは、リクエストの URL が /アプリ１を示す文字列/ から始まる場合のみ適用されることになります。したがって、リクエストの URL が /アプリ１を示す文字列/signup/ の場合に views.signup が実行されることになります。
こんな感じで、ウェブアプリの受け付けるリクエストは プロジェクト/urls.py と アプリ/urls.py の path 関数の第１引数で指定した文字列を結合した URL となるので注意してください。
とりあえず、このページでの urls.py に関しての説明は以上となります。この urls.py に関しては次の連載となる下記ページで詳細を解説していますので、下記ページでより深く学んでいきましょう！
【Django入門３】ビュー（View）の基本とURLのマッピング
スポンサーリンク
views.py
次に、views.py について説明していきます。
views.py の役割
views.py は、前述のとおり MTV モデルにおける View に該当するファイルであり、ウェブアプリの機能を実装するファイルとなります。言い換えれば、ウェブアプリの機能を提供するファイルとなります。
つまり、views.py で実装した関数（or クラス）が “ウェブアプリの機能” に該当することになり、そして、ウェブアプリがリクエストを受け付けた際に、これらの関数やクラスが実行されることで、リクエスト送信元のクライアントが機能を利用することができることになります。
urls.py の節で説明したように、リクエストを受け付けた際に実行される関数は urls.py で URL と対応付けされることになりますが、この関数に該当するのが views.py で定義する関数となります。
また、views.py はクラスを利用して実装することも可能なのでですが、ここでは関数で実装することを前提に解説を進めます。
views.py の作り方
views.py はウェブアプリの機能を実装するファイルなので、基本的には自身で開発したいウェブアプリの機能に合わせて自身の好きなように関数を実装していけばよいことになります。また、ウェブアプリには複数の機能が備えられることが多いので、views.py には複数の関数を実装することになると思います。
ただ、views.py で実装する関数には守るべき最低限のルールが存在します。それが下記となります。
- 引数で “リクエスト” を受け取ること
- 正常終了時には返却値で “レスポンス” を返却すること
- 異常が発生したときには例外を発生させること
この “リクエスト” とは、Django フレームワークで定義される HttpRequest のサブクラスのインスタンス（オブジェクト）であり、“レスポンス” とは Django フレームワークで定義される HttpResponse のサブクラスのインスタンス（オブジェクト）になります。サブクラスと書いていますが、別に HttpRequest そのもの or HttpResponse そのもののインスタンスであっても良いです。
上記のようなルールが存在するのは、この views.py で定義する関数が Django フレームワークから実行されるためです。urls.py の節でも説明したように、urls.py によって関連付けられた関数は Django フレームワークから実行されることになります。
そして、この Django フレームワークは、関数を実行するときに引数として HttpResponse のサブクラスのインスタンスを指定し、関数から返却された返却値を HttpResponse のサブクラスのインスタンスとして扱うようになっています。
また、views.py で定義する関数の実行時に異常が発生したときは例外を受け取ることを前提とした作りになっています。このように Django フレームワークが作られているため、Django フレームワークから実行される関数は Django フレームワークに合わせて作成する必要があります。これは、上記のようなルールで関数を実装することで満たすこができます。
urls.py で URL にマッピングされていない関数は Django フレームワークからは直接実行されないため、上記のルールを満たす必要はありません
逆に言えば、上記の３つのルールさえ満たせば、この views.py は Django におけるウェブアプリの機能として成立することになります。
つまり、下記のような index 関数でも、Django におけるウェブアプリの機能として成立することになります。この index 関数では、関数内では使用していませんが、仮引数 request を指定しておくことで HttpRequest のサブクラスのインスタンスを受け取りることができるようになっています。そして、HttpResponse クラスのコンストラクタを実行して HttpResponse のインスタンスを生成し、それを返却しています。例外は発生しない作りとしていますが、上記のルールを満たした関数となります。
from django.http.response import HttpResponse
def index(request):
return HttpResponse('Hello World')この index 関数が Django フレームワークから実行されれば、HttpResponse クラスのインスタンスが Django フレームワークに返却され、Django フレームワークを経由して Hello World をボディとしたレスポンスがクライアントに返却されることになります。クライアントがウェブブラウザであれば、Hello World が画面に表示されることになります。
つまり、超簡単になりますが、ウェブアプリとしては機能することになります。
このように、ウェブアプリの機能となる views.py の関数は、HttpRequest のサブクラスのインスタンスを受け取るための仮引数を持ち、さらに HttpResponse のサブクラスのインスタンスを返却するように実装する必要があることは重要なポイントになるので覚えておきましょう！
メソッドに応じた処理の切り替え
もう１つ、views.py で定義する関数でポイントになるのが、リクエストのメソッドに応じた処理の切り替えが必要になるという点になります。
ウェブアプリが動作する環境・ウェブアプリの動作の流れ でも説明したように、ウェブアプリでは受け取ったリクエストのメソッドと URL に応じた機能を実行する必要があります。この URL に応じた機能の実行は、urls.py の節でも解説したように urls.py によって実現できることになります。
それに対し、メソッドに応じた機能の実行に関しては views.py によって実現する必要があります。つまり、views.py で定義する関数では、リクエストのメソッドに応じて実行する処理を切り替える必要があることになります。
で、これを実現するために、引数として渡される HttpRequest のサブクラスのインスタンスを利用することになります。このインスタンスのデータ属性 method には、リクエストのメソッドが文字列としてセットされているので、このデータ属性 method からメソッドを判断し、そのメソッドに応じた機能が実行されるように views.py の関数で条件分岐を実装してやれば良いことになります。
def index(request):
if request.method == 'GET':
# GETに対応する機能の処理を実装
elif request.method == 'POST':
# POSTに対応する機能の処理を実装
# ～略～このような、views.py の関数での “メソッドによる条件分岐” と、urls.py での “URL と関数とのマッピング” により、リクエストのメソッドと URL に応じた機能の実行が実現できることになります。
ただし、views.py に定義する全ての関数で method に応じた条件分岐が必要になるというわけではないです。特定のメソッドしか受け付けないような URL の場合は、データ属性 method に応じた条件分岐は行わず、受け付けるメソッドに対する１つの機能のみを関数内に実装することもあります。
また、メソッドに関わらず、views.py に定義する関数は必ず HttpResponse のサブクラスのインスタンスを返却する必要がありますので、この点には注意してください。
views.py からの Model と Template の利用
少し話を戻して、前述で一番簡単な views.py の関数の例を示しました。この関数では、必ず Hello World をボディとするレスポンスが返却されることになります。
from django.http.response import HttpResponse
def index(request):
return HttpResponse('Hello World')ただ、このような機能だと何の面白みもないウェブアプリとなってしまいます。上記の例の場合は真っ白な画面に Hello World と表示されるだけ…。
もっと面白みのあるウェブアプリ、価値のあるウェブアプリ、使っていて楽しくなるようなウェブアプリを開発していくためには、そのような特色を出せるような機能を検討し、それを実装していく必要があります。そして、この機能は views.py に実装していくことになります。
ただ、機能の全てを views.py に実装していくと views.py が複雑になってメンテナンスが大変になってしまいます。なので、下記ページでも解説しているように、Django では、View (views.py) は MTV における Model と Template を利用して開発することになります。この Model の役割を担うのが models.py で、Template の役割を担うのが templates フォルダ以下 のファイルとなります。
【Django入門１】Djangoとは？
Model を利用することで、データベースを利用してデータを保存したり、データベースからデータを取得することができるようになります。例えば、この Model を利用してユーザーをデータベースで管理すればログイン機能などを実現することができますし、ユーザーとツイートを管理すれば Twitter のようなウェブアプリも実現できます。
また、Template を利用することで、データベースで管理するデータの表示を効率的に実現することができるようになりますし、この Template でウェブアプリの画面（ページ）を美しく・きれいに・可愛く・かっこよく仕立てることもできます。
ここからは、これらの models.py と templates のフォルダ以下 についての説明をしていきたいと思います。
models.py
ということで、次は models.py について解説していきます。
models.py の役割
models.py は、Django における MTV の Model の実装先となるファイルとなります。Model はデータベースの管理・操作を行うことを役割としており、この Model を View (views.py) から利用することで、ウェブアプリのデータの保存機能や、保存したデータの取得機能を実現することが出来ます。
例えば、ウェブアプリではユーザー登録やログインが必要なものが多いです。これらの機能に関してもデータベースを利用して実現されることが多いです。ユーザーの登録はデータベースへのユーザーの情報（ユーザー名とパスワードを含む）の保存によって実現できますし、ログインに関しては、ユーザーが入力したユーザー名とパスワードを、データベースに保存されたユーザー名とパスワードと照合することで実現できます。
他にも、掲示板への投稿に関してはデータベースへのコメントの保存、掲示板の表示に関してはデータベースからのコメントの取得によって実現できます。ゲームであれば、対戦成績をデータベースに保存して、後からランキング化するようなこともできます。
こんな感じで、ウェブアプリではデータベースを活用することで様々な機能を実現することが可能です。MTV モデルにおいて、機能を実現するのは View になりますが、機能を実現する上で必要なデータベースの操作は Model で実現し、その Model を View から利用することで、データベースを利用する機能を実現していくことになります。
基本的には、ウェブアプリで何らかのデータを保存する際は必ずデータベースを利用すると考えて良いと思います。なので、データの保存を行うウェブアプリを実現するときには Model、つまり models.py の実装が必要となります。
models.py の作り方
続いて models.py の作り方について解説していきます。
models.py には、データベースの操作を行うクラスの定義を行う必要があります。そして、そのクラスを View (views.py) に利用してもらい、View からデータベース操作・管理が行えるようにします。
データベースの操作を行うクラスと聞くと難しそうに感じますが、実は、このようなクラスは超簡単に実現することができます。Django フレームワークには Model というクラスが存在し、この Model クラスにはデータベースの操作を行うメソッドが定義されています。なので、この Model というクラスを継承するサブクラスを定義してやれば、データベースの操作を行うクラスが定義できることになります。
例えば下記の Person クラスは Model を継承しているため、データベース操作が可能なクラスとなります。
from django.db import models
class Person(models.Model):
passなんですが、Model には “管理するデータ” が定義されていません。なので、上記のように単に Model を継承しても、データベースの操作を行うメソッドは利用できるものの、データベースで何もデータが管理できないことになります。
そのため、単に Model を継承するだけでなく、クラス変数としてデータベースで管理するデータを定義する必要があります。このデータベースで管理するデータの定義も含めた Person クラスの定義例は下記となります。このクラスを利用すれば、クラス変数の名称となる username・age・height・weight のデータを管理するデータベースが操作可能となります。
from django.db import models
class Person(models.Model):
username = models.CharField(max_length=20)
age = models.IntegerField()
height = models.FloatField()
weight = models.FloatField()また、クラス変数の定義における右辺は、そのデータの型を表します。例えば username = models.CharField(max_length=20) は、username の型が文字列（最大 20 文字）であることを示しています。その他のデータは整数型であることを示しています。
このように、models.py では、Model を継承するクラスを定義し、さらにデータベースで扱うデータをクラス変数として定義することが最低限必要となります。
Model のサブクラスとデータベースとの関係性
models.py の作り方の基本については理解していただけたのではないかと思います。
では、この models.py で Model のサブクラス を定義することにはどんな意味があるのでしょうか？この点について解説していきます。
結論としては、Model のサブクラス はデータベースにおけるテーブルであり、この Model のサブクラス を定義しておくことで、Model のサブクラス に対応したテーブルをウェブアプリ内で扱うことが出来るようになります。また、Model のサブクラス のインスタンスは、そのテーブルのレコードとして扱われます。
データベースでデータを管理するとは、具体的にはデータベース内に存在するテーブルにレコードを保存したり、テーブルからレコードを取得したり、テーブルのレコードを更新したりする操作のことを言います。つまり、データベースでデータを管理するとは、テーブルに対して操作・処理を行うことを言います。したがって、データベースでデータを管理するためにはテーブルが必要となります。
さらに、このテーブルには、テーブル特有の列が存在します。この列のことをカラムやフィールドと呼びます（Django でウェブアプリを開発する場合はフィールドと覚えた方が分かりやすいと思います）。そして、このテーブルのフィールドによってテーブルで扱うことのできるデータが決まることになります。つまり、テーブルでデータを扱うためには、テーブルの持つフィールドを定義しておく必要があります。
で、この “テーブルの持つフィールド” の定義は、ソースコード的には Model のサブクラス を定義することで実現することになります。
ここで再度、先ほど示した Model のサブクラス の定義例を確認してみましょう！
from django.db import models
class Person(models.Model):
username = models.CharField(max_length=20)
age = models.IntegerField()
height = models.FloatField()
weight = models.FloatField()この Model のサブクラス では、右辺の値を models.XxxxField() としたクラス変数を定義しています。このような、値が models.XxxxField() であるクラス変数がテーブルにおけるフィールドとなります。クラス変数名がフィールド名（列名）であり、クラス変数の値、すなわち右辺がフィールドで扱うデータの型となります。
で、上記のように Model のサブクラス を定義しておくと、ウェブアプリで下の図のようなテーブルを扱うことができるようになります。このテーブルは、id のように自動的に追加されるフィールドもあるのですが、Model のサブクラス のクラス変数と同じフィールドを持つことになります。
また、この Model のサブクラス のインスタンスはレコードとして扱われます。レコードとは、テーブルの一行分のデータになります。つまり、レコードはテーブルと同じフィールドを持つことになり、これは、Model のサブクラス のインスタンスが、Model のサブクラス のクラス変数と同じ名前のデータ属性を持つことを意味します。
そして、このインスタンスにメソッドを実行させることで、そのインスタンスに対応するレコードをテーブルに保存したり、テーブルから削除したりすることができます。さらに、テーブルからレコードを取得することもでき、この取得したレコードは Model のサブクラス のインスタンスとして扱うことが出来ます。
これらの Model のサブクラス のインスタンスの生成・取得、さらにはインスタンスからのメソッドの実行は View、つまり views.py で定義される関数から実行されることになります。
例えば、上記の Person クラスのインスタンス生成し、このインスタンスのデータ属性に適当な値をセットして save メソッドを実行させれば、そのインスタンスが Person クラスのテーブルにレコードとして保存されることになります。
こんな感じで、ウェブアプリで扱うデータベースのテーブルのフィールドは models.py の Model のサブクラス のクラス変数によって決まること、さらに Model のサブクラス のインスタンスはテーブルのレコードであり、このインスタンスにメソッドを実行させることでテーブルへの操作が実現できることは覚えておきましょう！
また、テーブルそのものに対する操作はマネージャーと呼ばれるものを使用して実行することになります。例えばテーブルからレコードを検索するような操作にはマネージャーを利用します。このあたりも含めた Model の詳細に関しては、別途下記ページで解説を行います。
【Django入門６】モデルの基本
ただ、Model のサブクラス を定義するだけだとテーブルは作成されません。そして、テーブルが作成されていないのにテーブルに対してレコードの操作を行おうとすると例外が発生することになります。ということで、Model のサブクラス を行った後はテーブルの作成を行う必要があります。このテーブルの作成はマイグレーションによって実現可能で、マイグレーションは manage.py を利用して実行することが可能です。これに関しては、後述の Django のプロジェクトの作り方・ウェブアプリの動かし方 の節で説明していきます。
templates フォルダ以下
続いて templates フォルダ以下 のファイルについて解説していきます。
templates フォルダ以下 の役割
この templates フォルダ以下 のファイルは、MTV モデルにおける Template の役割を果たすファイルであり、Template は、HTML の雛形となるテンプレートファイルを提供します。提供先は View になります。
ウェブアプリとは で説明したように、ウェブアプリはリクエスト受け取ったら機能を実行し、その機能から得られた結果に応じたレスポンスを返却する必要があります。基本的には、レスポンスのボディは HTML であると考えて良いです。そして、ウェブブラウザは HTML を受け取り、その HTML に基づいてページを描画することになります。
このような HTML を生成するために、View は Template のテンプレートファイルを利用することになります。そして、このテンプレートファイルを提供するのが Template、すなわち templates フォルダ以下 となります。
テンプレートファイルとは
このテンプレートファイルは、動的に HTML を生成するためのファイルとなります。基本的な構造は HTML と同じなのですが、変数やループ等の簡単なプログラムを扱うことが可能という点が HTML と異なります。例えば、テンプレートファイルで変数を扱うことで、その変数部分を動的に変化させて HTML を生成したり、ループを組んで同じ構造の箇所を動的に複数生成して HTML を生成したりすることが可能です。まずは、このページでは変数のみに注目して説明していきたいと思います。
ウェブアプリのページは、ページの種類が同じであれば、ページの構造自体は同じであることが多いです。ただし、構造は同じでも表示されるデータはリクエストによって異なることになります。つまり、ウェブアプリのページは、ページの雛形に対し、リクエストに応じて異なるデータを動的に埋め込むことで作成することができることが多いです。
例えば、SNS 等のウェブアプリでユーザーのプロフィールを表示するようなページを考えると、これらのページのデータ（ユーザー名や年齢など）はユーザーごとに異なるかもしれませんが、ページとしての構造（雛形）は同じです。
なので、雛形に対し、表示するユーザーの情報を埋め込んでやれば、表示対象のユーザーに応じて異なるプロフィールページを表示することが可能となります。
こんな感じで、ページの雛形のみを予め用意しておき、さらに雛形以外の部分を変数化しておけば、その雛形への変数の埋め込みのみを行うことで、様々なページの表示が可能となります。実際には、ページは HTML から描画されるので、HTML として雛形を用意しておくことになります。そして、この雛形となる HTML がテンプレートファイルとなります。このテンプレートファイルの作り方については後述で解説します。
このテンプレートファイルを提供することを役割とするのが Template となります。通常ウェブアプリは複数の種類のページを表示できるようになっているため、Template は複数のテンプレートファイルを提供することになります。そして、このテンプレートファイルの提供先は View となります。
つまり、Template は必要なテンプレートファイルを提供するだけで、View が適切なテンプレートファイルを選択し、そのファイルにデータを埋め込んで HTML を生成し、さらにそれをレスポンスとして Django フレームワークに返却する必要があります。
データベースのデータに基づいて HTML を生成
このテンプレートファイルから HTML を生成するにあたってポイントになるのが「テンプレートファイルに埋め込むデータ」になります。
ここまでの解説を読んでくださった方なら既に予想できているかもしれませんが、このテンプレートファイルに埋め込むデータは「データベースで管理されているデータ」であることが多いです。
ウェブアプリとは で説明したように、ウェブアプリは「リクエスト受け取ったら機能を実行し、その機能から得られた結果に応じたレスポンスを返却するアプリ」です。そして、この機能はデータベース操作であることが多く、その場合はデータベースの操作結果に応じたレスポンス (HTML) を返却することになります。
例えば、xxx さんのプロフィールページを表示するのであれば、xxx さんの情報を予めデータベースで管理するようにしておき、xxx さんのプロフィールページを表示したいというリクエストを受け取ったときに、xxx さんの情報をデータベースから取得し、それをテンプレートファイルに埋め込んで HTML を生成する感じですね。
データベースの操作自体は Model が行うことになりますが、その Model を利用するのは View になります。また、テンプレートファイルへのデータの埋め込みを行うのも View になります。なので、View、すなわち views.py の関数は下記のような処理を実行する必要があることになります。
- ①：Model を利用してデータベースの操作を行う
- ②：Template から提供されるテンプレートファイルを選択する
- ③：①の結果を②のテンプレートファイルに埋め込んで HTML を生成する
- ④：HTML をボディとするレスポンスを返却する
ただし、③と④に関しては、Django フレームワークから提供される render 関数を実行することで実現できます。①と②の結果を引数に指定して render 関数を実行すれば、テンプレートファイルからの HTML の生成が行われ、それをボディとする HttpResponse のインスタンスを返却値として取得することができます。
なので、基本的には View は①と②を行なった後に render 関数を実行し、その結果を Django フレームワークに返却すれば良いだけになります。
この処理の流れは、views.py で定義する関数の処理の流れの基本となりますので、是非覚えておきましょう！
テンプレートファイルの作り方
次にテンプレートファイルの作り方について説明していきます。
テンプレートファイルの拡張子は .html であり、アプリのフォルダに templates フォルダを、さらに templates フォルダの下に アプリ名 のフォルダを作成し、そのフォルダの下にテンプレートファイルを設置することになります。
このテンプレートファイルは、基本的には HTML と同様の構造のファイルとなります。ただし、単なる HTML は静的なファイルであり、動的に変化させることができません。動的に変化させるためには、Django のテンプレートファイルならではの記述が必要となります。これを Django テンプレート言語と呼びます。
例えば、変数を埋め込み可能なテンプレートファイルを作成する場合、その変数を埋め込み可能にしたい部分を {{変数名}} と記述する必要があります。そして、テンプレートファイルから HTML を生成する際に、後述で説明するコンテキストというデータによって {{変数名}} 部分に埋め込むデータを指定すれば、そのデータが {{変数名}} の部分に埋め込まれた HTML が生成されることになります。なので、コンテキストのデータを動的に変化させることで、１つのテンプレートファイルから無数の HTML が生成できることが可能です。
例えば、下記のようなテンプレートファイルの場合、{{username}}、{{age}}、{{height}}、{{weight}} の部分は変数として扱われることになります。
<!DOCTYPE html>
<html lang="'ja">
<head>
<meta charset="utf-8">
<title>プロフィール</title>
</head>
<body>
<h1>プロフィール</h1>
<div>
<h2>{{username}}の情報</h2>
<p>年齢：{{age}}</p>
<p>身長：{{height}}</p>
<p>体重：{{weight}}</p>
</div>
</body>
</html>変数以外にも条件分岐やループを行うような命令や、さらに埋め込むデータを加工するようなフィルター処理をテンプレートファイルに実装することもできます。
このあたりの詳細に関しては、下記の Template の解説ページで別途説明を行いたいと思います。
【Django入門４】テンプレート（Template）の基本
テンプレートファイルからの HTML の生成
ついでに、前述で少し触れた render 関数についても説明しておきます。render 関数は、前述のとおり、テンプレートファイルへのデータの埋め込みを実行して HTML を生成する関数となります。そして、render 関数は、その HTML をボディとするレスポンスとなる HttpResponse のインスタンスを返却します。
render 関数は HttpResponse のインスタンスを返却しますので、View (views.py に定義する関数) は render 関数の返却値をそのまま返却してやれば良いことになります。これで、View の関数を作成するときのルールの１つである「返却値でレスポンスを返却すること」を自然と満たすことが出来ます。
また、View は、render 関数を実行する前に、リクエストに応じた機能の実行（データベースの操作）及びテンプレートファイルの選択を行う必要があります。そして、render 関数を実行する時に、選択したテンプレートファイル（のパス）とテンプレートファイルに埋め込みたい “コンテキスト” を引数に指定する必要があります。このコンテキストは、言ってしまえば辞書で、このコンテキストの各要素に '変数名': データ を持たせることで、{{変数名}} 部分に埋め込むデータを指定することが出来ます。
なので、コンテキストを機能の実行結果（データベースの操作結果）に応じて作成するようにしてやれば、生成される HTML は “機能から得られた結果に応じた HTML” となり、ウェブアプリに必要となる “機能から得られた結果に応じたレスポンスを返却する” を満たすことができるようになります。
views.py に定義する関数として、典型的な処理の流れの例として実装した関数が下記となります。
from django.shortcuts import render
from .models import Person
def index(request, person_id):
person = Person.objects.get(id=person_id)
context = {
'username' : person.username,
'age' : person.age,
'height' : person.height,
'weight' : person.weight,
}
return render(request, 'testapp/index.html', context)この関数では、まず引数で指定された person_id の値を id フィールドに持つレコードをデータベースから取得しています。Person.objects.get(id=person_id) が、models.py の節で少しだけ触れたマネージャーによるテーブルの操作となります。このようにテーブルから特定のレコードを検索して取得するような処理に関してはマネージャーを利用することになります。
次に、そのレコード person の username・age・height・weight フィールドの値に基づいてコンテキスト context を生成しています。最後に、render 関数を実行し、第２引数に指定したパスのテンプレートファイルに対して context の各要素で指定されたデータをテンプレートの変数部分に埋め込んで HTML を生成しています。そして、その HTML をボディとする HttpResponse のインスタンスを返却しています。
render 関数では、context の各キーの値が、前述で紹介したテンプレートファイルにおける {{変数名}} の部分に埋め込まれることになります。具体的には、{{username}} の部分に person.username の値が、{{age}} の部分に person.age の値が埋め込まれるといった感じですね。
person はデータベースから取得されたレコードですので、データベースから取得したデータに応じて生成される HTML が動的に変化することになります。さらに、クライアントからのリクエストに応じて取得するレコードを変化させれば、クライアントのリクエストによって HTML が変化することになります。
こんな感じで、リクエストに応じたレスポンスを返却することを実現するためのファイルがテンプレートファイルとなります。
送信フォームの設置
また、ウェブアプリでは、クライアントからのデータの送信を実現するために、下の図のようなフォームをページに設置することが多いです。こういったフォームでデータを送信することで、例えばユーザー登録を行なったり、コメントを投稿したりすることができます。
こういったフォームに関しては、表示するフォームの定義を アプリフォルダ 内の forms.py で行い、それをテンプレートファイルに埋め込むことで表示することができます。
この辺りのフォームに関する解説に関しては下記ページで解説していますので、詳細に関しては下記ページをご参照ください。
【Django入門５】フォームの基本
スポンサーリンク
Django のプロジェクトの作り方・ウェブアプリの動かし方
次は、Django のプロジェクトの構成 で示したプロジェクトの作り方と、ウェブアプリの動かし方について解説していきます。
プロジェクトを作成する
まずはプロジェクト自体の作り方について解説していきます。
プロジェクトは、django-admin というプログラムを利用して作成することになります。この django-admin は Django インストール時に一緒にインストールされるプログラムになります。
プロジェクトを作成するときは、下記のように startproject と プロジェクト名 を引数に指定して django-admin を実行します。コマンドは、コマンドプロンプトや PowerShell やターミナル等のコマンドが実行可能なアプリから実行してください。
% django-admin startproject プロジェクト名
これにより、コマンドを実行した位置のフォルダ直下に プロジェクト名 のフォルダが生成されます。このフォルダの中の構成は下の図のようになっているはずです（図では __init__.py は省略しています）。
上の図のように、この プロジェクト名 のフォルダの中には manage.py と、もう１つの プロジェクト名 のフォルダが生成されることになります。つまり、プロジェクト名 のフォルダの中に プロジェクト名 のフォルダが存在することになります。以降では、この内側に存在する プロジェクト名 のフォルダのことを プロジェクト設定フォルダ と呼ばせていただきます。
アプリを作成する
続いてアプリを作成していきます。
まず、アプリフォルダ を作成し、続いて アプリフォルダ 内のファイルを変更していくことになります。
アプリフォルダ を作成する
アプリフォルダ は manage.py を利用して自動生成することができます。manage.py に関しては、先ほど実行しした django-admin startproject によって自動的に生成されます。
具体的には、アプリフォルダ は下記のように startapp と アプリ名 を引数に指定して manage.py を実行することで自動的に生成することが出来ます。このコマンドは、先ほど自動生成された プロジェクト名 のフォルダ内で実行する必要があります。
% python manage.py startapp アプリ名
これにより、プロジェクト名 のフォルダの下に、すなわち プロジェクト設定フォルダ と同階層に アプリ名 のフォルダが生成されるはずです。この アプリ 名のフォルダが アプリフォルダ となります。
ここまで説明してきた views.py や models.py が アプリフォルダ の中に自動生成されていることも確認できると思います。ただ、urls.py や forms.py、さらには templates フォルダ は自動生成されません。これらのファイルやフォルダも、結局ウェブアプリを開発するときに必要になることが多いので手動で追加しておくことをお勧めします。また、 templates フォルダ の下には アプリ名 のフォルダも必要となりますので、このフォルダも忘れずに作成しておきましょう。
手動で必要になるファイルを追加すれば、プロジェクト名 フォルダ以下の構成は下の図のようになるはずです（図では __init__.py は省略しています）。
アプリを開発する
必要なフォルダ・ファイルが用意できれば、次は実際にアプリを開発していくことになります。具体的には アプリフォルダ 内の特に下記を編集してアプリを開発していくことになります。必要に応じて forms.py の編集も必要となります。
views.pymodels.pytemplates フォルダ以下urls.py
これらのファイルの役割や作り方については既に Django のプロジェクトの構成 で説明しましたし、今後個別の解説ページで詳細を解説していきますので、ここでの詳細な解説は省略させていただきます。
スポンサーリンク
プロジェクトの設定を行う
続いて、プロジェクトの設定を行っていきます。
アプリの登録
プロジェクトの設定は、主に、プロジェクトフォルダに存在する settings.py で行うことになります。
settings.py では、Django フレームワークおよび、プロジェクト内のアプリの共通の設定を行うことができます。様々な設定が可能で、例えば使用するデータベース管理システムを変更するようなことも可能です。
settings.py で設定可能な項目の調べ方は下記ページで解説していますので、詳しく知りたい方は下記ページをご参照ください。
【Django】settings.py での設定可能項目やデフォルト値の調べ方
で、Django でウェブアプリを開発する際、settings.py で必ず行う必要のある設定が「アプリの登録」になります。Django フレームワークの機能は アプリフォルダ のファイルから利用することもできますが、逆に アプリフォルダ のファイルや関数は Django フレームワークから利用されるものでもあります。
例えばですが、アプリフォルダ の models.py は起動時に Django フレームワークから読み込まれることによって、他のファイルから models.py で定義されたモデルを利用できるようになります。
ただ、このような Django フレームワークからの アプリフォルダ の利用が実現できるのは、Django フレームワークがそのアプリを認識しているからであって、アプリを認識していなければ アプリフォルダ のファイルを利用することはできません。
そのため、アプリの存在を Django フレームワークに認識させる必要があります。このために行うのが settings.py でのアプリの登録になります。このアプリの登録は、settings.py で INSTALLED_APPS というリストの要素に アプリ名 を追加する必要があります（もしくは アプリフォルダ の apps.py で定義されるクラスを指定するのでも良いです）。
例えば下記は、'testapp' という名前のアプリを登録する例となります（１行目に追記しています）。
INSTALLED_APPS = [
'testapp', # 'testapp.apps.testapp'でも可
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]これによって Django フレームワークが登録されたアプリを認識し、そのアプリに対する アプリフォルダ 以下のファイルが Django フレームワークから利用されるようになります。上記では１つのアプリのみを登録していますが、複数のアプリを登録することも可能です。
また、実際に settings.py を確認してみると分かると思いますが、自動生成された時点で settings.py の INSTALLED_APPS にはデフォルトで複数のアプリが登録されていることになります。
例えば django.contrib.admin は Django フレームワークにおける管理画面機能を実現するアプリであり、これがINSTALLED_APPS に登録されているため、管理画面を自身で開発しなくても管理画面の機能を利用することができるようになっています。また、django.contrib.auth は Django フレームワークにおける認証機能を実現するアプリとなり、認証機能を自身で開発しなくても認証機能を利用することができるようになっています。
こういったデフォルトで登録が行われているアプリも存在することや、こういったアプリと連携動作して自身が開発するアプリが動作し、それによって１つのウェブアプリが実現されていくということも覚えておくと良いと思います。
プロジェクト/urls.py の設定
もう１つ重要になる設定が、アプリフォルダ の urls.py の読み込みの設定になります。
これに関しては プロジェクトとアプリの urls.py で詳細を説明したので、ここでの説明は省略しますが、Django フレームワークから アプリフォルダ の urls.py が読み込まれるように、プロジェクト設定フォルダ の urls.py を作成する必要があります。
テーブルの作成
次は、データベースへのテーブルの作成を行います。
models.py の節でも説明したように、models.py に定義する Model のサブクラスがデータベースのテーブルとして扱われることになります。ですが、このテーブルは Model のサブクラスを定義するだけでは自動的に作成されません。このクラスを定義した上で、マイグレーションを実行することでデータベースにテーブルが作成されることになります。
そのマイグレーションは、下記の２つのコマンドを実行することになります。ここでも manage.py を利用することになります。
% python manage.py makemigrations
% python manage.py migrate
makemigrations コマンドで設定ファイルを作成する
１つ目の makemigrations コマンドは、models.py に定義されたクラスに基づいて「マイグレーションの設定ファイルを作成する」ためのコマンドになります。
つまり、このコマンドではデータベースにテーブルは作成されません。あくまでも models.py に定義されたクラスに基づいた設定ファイルを作成するのみです。ですが、２つ目の migrate コマンドでは、このファイルに基づいてテーブルの作成が行われることになるため、migrate コマンドを実行する前に makemigrations コマンドを実行しておく必要があります。
また、この makemigrations コマンドで作成される設定ファイルは アプリフォルダ の migrations フォルダの下に作成されます。最初に makemigrations コマンドを実行した際には 0001_initial.py が作成され、その中に models.py に定義されたクラスの情報が記述されています。
migrate コマンドでテーブルを作成する
さらに、２つ目の migrate コマンドでは、makemigrations コマンドによって生成された設定ファイルに基づいてデータベースへのテーブルの作成が行われることになります（既にテーブルが存在する場合はテーブルの更新が行われます）。
ウェブアプリを初めて開発する場合、データベース上にテーブルが存在しない状態となっている可能性が高いです。そのため、ウェブアプリでデータベースへのレコードの保存等を行いたいのであれば、まずは上記のような操作を行なってテーブルを作成しておく必要があります。
マイグレーションの実行タイミング
また、上記の操作によってデータベースに作成されるテーブルは、makemigrations コマンドを実行したタイミングにおける models.py に基づいたものになります。そのため、models.py を変更した場合は（特にクラスにクラス変数を追加・削除・変更した場合）、上記の２つのコマンドを再度実行してテーブルを更新する必要があるので注意してください。
２回目以降に makemigrations コマンドを実行した場合、前回 makemigrations コマンドを実行した時からの models.py の差分に基づいた設定ファイルが migrations フォルダに作成されることになります。そして、その後に migrate コマンドを実行することで、新たに作成された migrations フォルダの設定ファイルも含めてデータベースのテーブルの作成や更新が行われることになります。
データベース自体の作成も必要
ちなみに、上記ではデータベースのテーブルの作成について説明しましたが、テーブルを作成する前にデータベース自体の作成も必要となるので注意してください。
ただ、Django では、デフォルト設定では SQLite3 というデータベース管理システムが使用されるようになっており、この管理システムを利用する場合は、先ほど説明したマイグレーションを実行することでデータベース自体の作成も行われるようになっています。なので、デフォルト設定のまま SQLite3 を利用するのであれば、データベースの作成に関しては気にする必要は特にないです。
ただ、他のデータベース管理システムを利用する場合は別途データベース自体の作成も必要になることがあるので注意してください。Django 初心者の方であれば、まずは SQLite3 を利用してウェブアプリを開発することになると思うので、まずはデータベースの作成については気にする必要はありません。ですが、他のデータベース管理システムを利用する場合はデータベースの作成が別途必要となることが多いので、この点には注意してください。
ウェブアプリを動作させる
ここまでの設定を行えば、ウェブアプリを動作させる準備が整ったことになります。
準備が整ったら、後はウェブアプリを実際に動作させて動作確認を行いましょう！
開発用ウェブサーバーを起動する
Django の全体像 でも解説したように、ウェブアプリはウェブアプリ単体で動作するのではなく、ウェブサーバー等の他のソフトウェアと連携して動作することになります。ただ、これらのソフトウェアを用意するのは面倒なので、動作確認やテスト時には 開発用サーバーでのウェブアプリの動作確認 で紹介した開発用ウェブサーバーを利用してウェブアプリを動作させることになります。
そして、この開発用ウェブサーバーに関しても Django の場合は manage.py を利用することで起動することが可能です。
具体的には、下記のコマンドを実行することで開発用ウェブサーバーが起動します。
python manage.py runserver
これにより、開発用ウェブサーバーが起動し、クライアントからのリクエストを待ち続けている状態になります。そして、リクエストを受信した際には、Django フレームワークがリクエストを受け取り、さらにプロジェクト内のファイルの読み込みや関数の実行が行われることになり、これによってウェブアプリが動作することになります。
どれだけ頑張ってウェブアプリを開発したとしても、この開発用ウェブサーバーを起動しないとウェブアプリは動作すらしないので注意してください。
１つ補足しておくと、デフォルト設定では、開発用ウェブサーバーはポート番号 8000 でリクエストを待つようになっています。異なるポート番号でリクエストを待ちたい場合は、下記のように runserver の引数にポート番号を指定するようにしてください。
python manage.py runserver 80
スポンサーリンク
リクエストを送信する
開発用ウェブサーバーを起動したら、次はリクエストを送信して実際にウェブアプリの動作確認を行うことになります。
このリクエストはウェブブラウザから送信可能で、ウェブブラウザのアドレスバーにウェブアプリが受け付けるリクエスト、すなわち各種 urls.py で定義した URL を指定してやれば、その URL に対するリクエストが開発用ウェブサーバーに送信されることになります。
ただし、URL は絶対パスで指定する必要があるので注意してください。開発用ウェブサーバーを起動した PC と同じウェブブラウザで動作確認を行うのであれば、下記のような形式の URL をウェブブラウザのアドレスバーに指定する必要があります。
http://127.0.0.1:8000/xxxx/yyyy/
また、 ウェブアプリが受け付け可能な URL をリンク先に設定したリンクテキストをページに表示するようにしておけば、それをクリックすることでもウェブアプリに対してリクエストを送信することができるようになります。
さらに、リクエストの送信に関しては、下記ページで紹介している requests モジュールを利用すれば Python スクリプトから実施することができます。
【Python】reqeustsモジュールについて解説
【Python】requestsモジュールでPOSTメソッドのリクエストを送信（ウェブアプリの操作）
このように、様々なリクエストの送信方法があるのですが、まずはアドレスバーに直接 URL を指定するのが無難だと思います。
レスポンスを確認する
リクエストを送信すれば、開発用ウェブサーバーがリクエストを受信し、そのリクエストをウェブアプリが受け取ることになります。具体的には、urls.py でリクエストの URL にマッピングされた views.py の関数が実行されることになります。そして、views.py の関数の返却値に基づいたレスポンスを、開発用ウェブサーバーを経由してウェブブラウザが受信することになります。
これによって、送信されたリクエストの URL に基づいたページがウェブブラウザに表示されますので、この表示結果からレスポンスの内容を確認することができます。意図した通りのページが表示されているかどうかをチェックしてみましょう！
こんな感じで、基本的にはウェブブラウザでリクエストの送信とレスポンスの確認を行うことで、ウェブアプリの動作確認を行うことになります。
Django のウェブアプリ内部の動作の流れ
ここまでプロジェクト内のファイルの構成や各ファイルの役割、さらにプロジェクトの作り方について解説してきました。
最後に、Django で開発したウェブアプリ内部の動作の流れについて、特にプロジェクト部分に注目しながら説明しておきたいと思います。
ここでは 開発用ウェブサーバーでのウェブアプリの動作確認 で紹介した開発用ウェブサーバーを利用する場合の動作について解説していきます。ウェブサーバーや AP サーバーを利用した場合は多少動作が異なるので注意してください。
スポンサーリンク
settings.py の読み込み
Django 開発用ウェブサーバーを利用する場合、Django 開発用ウェブサーバーを起動した際にウェブアプリのセットアップが行われることになります。
最初に行われるのは settings.py の読み込みになります（読み込みとは、具体的には import のことを言っています）。
アプリの登録 で少し説明しましたが、settings.py はウェブアプリにおける Django フレームワーク部分の動作の設定を行うものであり、この読み込みが行われることで、settings.py での設定に基づいて Django フレームワークが動作するようになります。
また、ウェブアプリを動作させるという点でポイントになるのが、アプリの登録 での INSTALLED_APPS の設定になります。この設定により Django フレームワークがプロジェクト内の アプリフォルダ の存在を認識し、settings.py の読み込みによって、INSTALLED_APPS に指定されたアプリのセットアップが行われます。
アプリのセットアップ
続いて、このアプリのセットアップの流れを説明していきます。
ここでは、アプリフォルダ のファイルの読み込みによってアプリのセットアップが行われていくことになります（詳しくは説明しませんが、下記のセットアップは settings.py の INSTALLED_APPS に指定されている全アプリに対して行われるものになります）。
apps.py の読み込み
アプリのセットアップにおいて、まず行われるのが アプリフォルダ の apps.py の読み込みになります。このページでは apps.py についての詳細は説明しませんでしたが、この apps.py はアプリの設定（名前など）を行うファイルになります。このファイルを変更することで、そのアプリならではのセットアップなども行うことが可能となります。が、まずは Django 入門者の方は apps.py は自動生成された状態のものをそのまま利用すればよいと思います。
この apps.py の読み込みにより、アプリに設定された情報（例えば名前など）を Django フレームワークが認識することになります。
models.py の読み込み
続いて、アプリ名 フォルダの models.py の読み込みが行われます。これにより、アプリで扱う Model のサブクラスを Djangoo フレームワークが認識することになります。models.py で解説したように、この Model のサブクラスはデータベースにおけるテーブルとして扱われ、さらに、このクラスのインスタンスはテーブルのレコードとして扱われます。
admin.py の読み込み
次に、アプリフォルダ の admin.py の読み込みが行われることになります。これにより、ウェブアプリの管理画面のセットアップが行われます。このファイルについても詳しくは説明しませんでしたが、このファイルを編集することで、ウェブアプリの管理画面から models.py で定義した Model のサブクラスのテーブルの操作を行うようなこともできるようになります。
この admin.py や管理画面については、下記ページで別途詳細を解説していますので、詳しくは下記ページをご参照いただければと思います。
【Django入門１１】管理画面（admin）の使い方の基本
以上が、INSTALLED_APPS に指定されている各アプリに対して実行されるセットアップ処理になります。
これらの一連のセットアップ処理は、あくまでも settings.py の INSTALLED_APPS に指定されているアプリに対して実行されるという点に注意してください。INSTALLED_APPS に自身が開発したアプリを指定しなかった場合、当然セットアップは実施されず、アプリのセットアップの後に実行される処理で例外が発生する可能性があります。
settings.py の INSTALLED_APPS のリストにアプリを指定することで、初めて Django フレームワークが、そのアプリを認識するという点をしっかり覚えておきましょう！
urls.py の読み込み
アプリのセットアップの後は、Django フレームワークから urls.py が読み込まれることになり、この読み込みによって、Django フレームワークがリクエストを受け取った際に、リクエストされた URL に応じて実行する関数を振り分けることができるようになります。
このときに読みこまれる urls.py は プロジェクト設定フォルダ 内のものになりますが、その urls.py の中で アプリフォルダ の urls.py を include するようにしている場合、プロジェクト設定フォルダ 内の urls.py を読み込む際に、アプリフォルダ の urls.py も読み込まれることになります。
また、特に アプリフォルダ の urls.py では URL と views.py とのマッピングを行うために views.py を import することが多いです。なので、この アプリフォルダ の urls.py の読み込み時には views.py や views.py から import されているモジュールのファイルが読み込みされることになります。views.py 等に文法的な誤りなどがあると、この時点で例外が発生してウェブアプリのセットアップに失敗するので注意してください。
スポンサーリンク
wsgi.py の実行
以上でウェブアプリの、特にプロジェクトのセットアップが完了したことになります。このセットアップ終了後に行われるのが プロジェクト設定フォルダ 内の wsgi.py の実行になります。
wsgi.py は、簡単に言うとウェブアプリの入り口と出口の役割を果たすファイルになります。違う言い方をすれば、上位のサーバーと Django フレームワークとの仲介を行うファイルです。
開発用ウェブサーバー等の、ウェブアプリの上位側のサーバーは、プロジェクトのセットアップ完了後に wsgi.py を実行して、wsgi.py で定義される “ウェブアプリの入り口となる呼び出し可能なオブジェクト” を取得します（以降、このオブジェクトをエントリーポイントと呼びます）。そして、上位のウェブサーバーがリクエストを受け取ったときには、このエントリーポイントを実行してウェブアプリを動作させることになります。
このエントリーポイント実行時には引数としてリクエストが渡されることになります（環境変数として渡される）。そして、このリクエストをエントリーポイントから Django フレームワークに渡してウェブアプリの機能が実行されることになります。また、Django フレームワークから受け取ったレスポンスを上位のサーバーに返却するのもエントリーポイントの役割となります。
こんな感じで、実は上位のサーバーとリクエストやレスポンスのやりとりを行うのは wsgi.py となります。最初は wsgi.py については意識せずにウェブアプリを開発すれば良いと思いますし、自動生成されたままの wsgi.py を利用するので問題ないと思いますが、wsgi.py の役割については覚えておくと良いと思います。
アプリの実行
ここまで説明してきた流れの処理が行われることで、開発用ウェブサーバーの起動・ウェブアプリ（Django フレームワークやプロジェクト）のセットアップが完了することになります。これらが完了すればウェブアプリが動作可能となり、開発用ウェブサーバーはウェブブラウザ等のクライアントからのリクエスト待ちの状態になります。
そして、クライアントからリクエストを受け取った際には、前述の通り、開発用ウェブサーバーから wsgi.py を経由して Django フレームワークにリクエストが渡されます。そして、この Django フレームワークからは urls.py の設定に基づいて views.py の関数やメソッドが実行されることになります。
さらに、views.py の関数からは、models.py で定義したクラスを利用してテーブルの操作が行われることになります。models.py では Model のサブクラス を定義することになるので、このテーブルの操作の際には Django フレームワークで定義された Model クラスが動作してテーブルの操作が行われることになります。
また、views.py の関数からは、テーブルの操作結果等を render 関数を使ってテンプレートファイルに埋め込み、その結果となる HTML をボディとした HttpResponse のインスタンスが返却されることになります。そして、こここで実行する render 関数からは引数で指定された templates フォルダ以下 に存在するテンプレートファイルが読み込まれて HTML の生成が行われることになります。
また、HttpResponse のインスタンスが views.py の関数から返却されることで、Django フレームワーク及び wsgi.py を介して開発用ウェブサーバーがレスポンスを受け取り、それがクライアントに返却されることになります。
こんな感じで、Django フレームワークとプロジェクト内のファイルが動作することでクライアントからウェブアプリが利用されることになります。特に、urls.py・views.py・models.py・templates フォルダ以下 の役割や関係性については重要となりますので、Django を利用するのであれば、この辺りはしっかり頭に入れておきましょう！
まとめ
このページでは、Django の全体像と Django の動作の仕組みについて解説しました！
Django で開発するウェブアプリは、大きく分けて Django フレームワークとプロジェクトの２つから構成されます。さらにプロジェクトはプロジェクト設定と１つ or 複数のアプリから構成されます。
プロジェクト設定は主に Django フレームワークの動作を設定するものであり、アプリはウェブアプリの独自の機能や動作を実現していくためのものであると考えると、これらの関係性がわかりやすくなると思います。
最初にも説明したように、Django を利用するデメリットは「慣れるまでが大変」である点だと私は考えています。このページで解説した Django の全体像や Django のウェブアプリの動作の仕組みを覚えておくだけでも Django に慣れやすくなると思いますので、是非このページで解説したことは頭の中に入れておいてください！
ここまでは Django の全体像を理解していただくことを目的に解説を行なってきましたが、次の連載からはウェブアプリを開発するために必要となる知識としてビューやテンプレート、モデル等の具体的な解説を行なっていきます。まずは、次の連載となる下記ページでビューについて解説を行なっていますので、是非下記ページも読んでみてください！
【Django入門３】ビュー（View）の基本とURLのマッピング