djangoを学び始めて最初に挫折してしまう原因は「全体像がつかめず、何をしているのかわからない」ということかもしれません。

今何をやっているのかが分からなければ、学ぶ意欲もわきませんよね。

djangoについて学び始める前に、この記事でdjango（フレームワーク）の全体像をつかんでいきましょう。

ここからの記事ではdjangoという言葉を中心に説明していきますが、djangoは「フレームワーク」に置き換えても大丈夫です。

はじめに、djangの仕組み（全体像）を図で紹介します。

この図をみても、恐らくほとんどイメージがわかないと思いますが大丈夫です。

ここで覚えておいてほしいことは、ブラウザからHttpリクエストを受け取ると、djangoが複雑なことをやってくれる。ということです。

ここから、具体例でdjango（フレームワーク）の仕組みへの理解を深めていきましょう。

ウェブサイトの一連の流れを出前に例えて考えていきましょう。

出前を頼むお客さんがブラウザで、注文をするのがリクエスト、届いた料理がレスポンスです。

まず、普通のウェブサーバー（普通の出前の場合）です。

今回は、ラーメンと寿司の店があったとしましょう。

あなたは、ラーメンを食べたくなったとします。

この時、お寿司の店に電話をかけて「ラーメンの注文をお願いします」といったらどうなるでしょうか？

「うちにはラーメンは置いていません」と言われてしまいますよね。

ラーメンの注文をするためには、ラーメンのお店に電話をしなければいけません。

つまり、こちら側の要求を、受け手側が理解できなければいけないのです。

一言でいうと、一対一の関係です。

次にフレームワークの場合です。

フレームワークの場合、注文を受けてくれる便利屋さんが間にいるようなイメージです。

何か食べたくなったので、便利屋に電話をしたとしましょう。

便利屋は、すしでもラーメンでも、あなたのリクエストに応じて対象となるお店に電話をし、注文をしてくれます。

簡単に整理すると、「どんなリクエストを受け取っても、それに対して応えてくれる仕組み」がフレームワークです。

注文を受けてくれる便利屋は一人ですが、その人がより多くの処理をすることができるというイメージを持つとよいかもしれません。

ただ、便利屋が知らないお店（リクエスト）の場合は「その料理は注文できません」と言われてしまうという点も頭に入れておきましょう。

レストランの例を見たうえで、改めてウェブサーバーとフレームワークの違いを見ていきましょう。

ウェブサーバーの場合の仕組みを図にしてみました。

レストランの例をイメージしながら、どういった流れになっているのかをみていきましょう。

まず、ブラウザでhttps://abc.com/news/z.htmlというリクエストを送ったとしましょう。

これは、abc.comというドメインにひもづいたサーバーの中の、news/z.hmtlファイルの中身を取ってきてくれ、というリクエストです。

この指示に基づいて、abc.comにひもづいたサーバーは、z.htmlというファイルを取り出し、これをブラウザに返します。

ここで意識しておきたいことは、ブラウザのリクエストと戻ってくるファイルは一対一の関係にあるということです。

一直線に狙った情報を取りに行く、というイメージが分かりやすいかもしれません。

次に、フレームワークの場合を見ていきましょう。以下の図をみてください。

ブラウザで、https://aa.com/postというリクエストを出したとしましょう。

この時、普通のウェブブラウザであればpostというファイルを一直線に探しにいくのですが、フレームワークの場合はそうではありません。

フレームワークの場合、どんなurlリクエストが来たとしても、まずは特定のファイルが呼び出されます。

この図の場合、urls.pyファイルが呼び出されます。

どんなurlがリクエストされても、urls.pyファイルを呼び出すようdjangoのサーバーの中で設定しているからです。

出前の例でいうところの「便利屋」がこのurls.pyファイルのイメージです。

そして、urls.pyファイルは、受け取ったurl（リクエスト）の内容と、urls.pyファイルに書かれている情報を照らし合わせます。

そして、合致した場合にはそれに対応した部分に書かれている内容に応じ、次の指示につなげていくようになっています。

出前の例で言うと、受けた注文に対し、どの店に連絡すればよいのか便利屋が知っていればその店に注文を出し、そうではない場合はエラーを出すようなイメージです。

urls.pyファイルは、いくらでもurlsの種類を書き足すことができます。

（便利屋にお店の情報をどんどん追加できるようなイメージです。）

ウェブブラウザの場合、一つのurlと一つのファイルが一対一の関係になるとお伝えしました。

urls.pyも、ある意味一対一の関係です。（上記の図の場合、urlの最後にpostがついていたら、それに対応する次の指示につなげるからです）

そうすると、あえてurls.pyのように一つのファイルが全てのurlを受けるようにする必要はないと思いますよね？

これに対する答えは、djangoを学んでいくなかで知っていく部分が多いのですが、一つ例をあげましょう。

例えば、100記事のブログを書いた場合を考えてみます。

普通のウェブサーバーの場合、xxx.com/1、xxx.com/2といった形で、一つのurlに対して一つの記事をひもづけていきますよね。

この時、1,2...という番号は、人が手動で割り振っていく必要があります。

その結果、番号が重複してしまったり、連続した番号にならない場合もあるでしょう。

フレームワークの場合、この通し番号を違う形で表現することができます。

例えば、urls.pyファイルにxxx.com/と書いたとしましょう。

このidは、djangoが備えているデータベースに格納された一つ一つの記事の番号に対応しています。

つまり、このように書くことで、ブラウザからxxx.com/5とリクエストを受けたら5番の記事を返し、xxx.com/10とリクエストを受けたら10番の記事が帰ってくるようにできるのです。

このように、手動でやると手間がかかることでも、フレームワークを使うことで簡単になるというイメージをまずは持ちましょう。

ちょっと長くて大変かもしれませんが、さらに理解を深めるために、データベースと連携したい場合についてみていきましょう。

例えば、ECサイトなどでログイン機能を持たせたい場合などです。

こういった場合、まずはユーザーの情報などを保存するデータベースを準備する必要があります。

一般的なウェブサーバーにデータベースを連携させた以下の図をみてください。

この図ではデータベースサーバーがデータを受け取ったり、データを返したりする機能を持っています。

具体的には、Httpリクエストにはログインの認証をするための情報も入っています。

そして、データを照合する機能をもったサーバーが入力されたデータとデータベースの中のデータを照らし合わせます。

そして、サーバーがログインの情報を照合することができたらログインされた後のhtmlファイルを表示し、照合できなければエラーの画面を出すようにします。

フレームワークを使うと、このようなイメージになります。

ユーザーから情報が入力されたときに、データベースと連携するまえに「django（緑色のボックス）」が入っていることに注目してください。

この「django」は、入力されたデータが正しいかどうかや、追加の情報を追加するなど、ただ一直線にデータベースにデータを運ぶのではなく、間にはいって処理をしてくれます。

便利屋が間に入って、何か便利なことをやってくれる。というイメージが分かりやすいのではないかと思います。

さきほどはECサイトの例をベースに、フレームワークがすごいということのイメージをわかせるため、実際のウェブサイトにおける実装の具体例について考えていきましょう。

これらは、djangoを使わなくても実装することはできますが、いざ実装しようとすると非常に手間がかかります。

このような場合において、フレームワークを使うと、簡単に実装をすることができます。

具体例と共にフレームワークについて説明してきました。