Djangoのアーキテクチャ全体像

　Djangoはもともとは、アメリカの新聞社の社内ツールとして2003年頃に開発され、2005年7月にBSDライセンスのもとで、オープンソースとして公開されました。

 

　Djangoのコアの部分は、データモデルとリレーショナルデータベース（以下、RDB）との間を仲介するO/Rマッパー、正規表現を活用したURLディスパッチャ、リクエスト要求を処理するビュー、データを表示するテンプレートシステムなどから構成され、Webアプリケーションフレームワークとして、フルスタックの機能を搭載しています。

 

　「The Web framework for pefectionists with deadlines（デッドラインにいる完璧主義者のためのウェブフレームワーク）」とDjango本家サイトのトップタイトルにも記載されているように、忙しい時でも、素早く簡潔できれいなアプリケーションが構築できることを目的にしています。

 

　Djangoの本家サイトにも多数の実績が掲載されており、豊富な稼働実績を持っているフレームワークです。

 

まずは、Djangoの全体像について説明します。Djangoのアーキテクチャを図2に示しました。

図2：Djangoのアーキテクチャ

MTVフレームワーク

　図2にコントローラがないことに違和感を感じられた方もいらっしゃると思います。Djangoプロジェクトでは、MVC（Model View Controller）のControllerを「View」、Viewを「Template」と呼び、MTV（Model View Template）フレームワークと称しています。これは、Djangoプロジェクトでは「どのデータを提示するか」をViewの役割と解釈し「どう見せるか」をTemplateの役割と解釈しているためです。MTVとMVCで呼び名は違いますが、全体動作の流れとしては大きな変わりはなく、解釈の違いだけであるので、あまり気にするところではないと思われます。

モデル（Model）

　モデルはDjangoで用意されているO/R（Object/Relational Database Mapper）マッパーが担当します。O/RマッパーはPythonクラスとしてモデルを定義するだけで、シンプルで使い勝手の良いデータベースへのインターフェイスを使用できるようにします。

　対話型インターフェイスが用意されており、O/Rマッパーの動作を逐次確認できるので、すばやく使い方を習得することができます。またDjangoのモデルは、電子メール型や電話番号型など、RDBのフィールド型だけでは表現できないフィールドも用意しているので、より実際のシステム仕様に近づいたモデルを表現することができます。Google App EngineのEntityモデルもDjangoのモデルに近いものを採用しています。

テンプレート（Template）

　Djangoのテンプレートシステムは、デザインとコンテンツ、Pythonコードの分離を目指したテンプレートエンジンです。テンプレート記述が複雑になることを防ぐため、あえてPythonとは別のテンプレート専用言語を採用しています。

ビュー（View）

　ビュー関数は、HTTPリクエストを引数にとり、HTTPレスポンスを返す関数です。ユーザーに「どのデータを提示するか」を決定するロジックを記述します。

コントローラ（Controller）

　Controllerは、URLのパスとそれに割り当てられ呼び出されるビュー関数のマッピングを記述するURLディスパッチ機構が担当します。このURLディスパッチ機構は正規表現を活用していて、フレームワークの仕様にしばられない柔軟なURL設計を実現できることが特徴です。

その他のDjangoの特徴的な機能

　MVTフレームワークの機能以外にもDjangoは有用な機能を搭載しています。それらの特徴的な機能についていくつか説明します。

キャッシュシステム

　Djangoは、memcachedや、その他のキャッシュフレームワークにデータを手軽にキャッシュできる仕組みを用意しています。この機構を利用することにより不特定多数のアクセスに耐えうるシステムを簡単に構築することができます。

国際化

　Djangoは、多言語のアプリケーションに対応しています。設定ファイルに言語とタイムゾーンを指定します。

管理インターフェイス

　モデル定義をもとにそのモデルのCRUD（Create、Read、Update、Delete）用の管理画面を提供する機能です。

　Webサービスでは一般に、そのサービスで提供される表向きの機能とは別に、データを管理するためのバックエンド（バックオフィス）用の画面が必要となります。これらの画面はほとんどの場合、決まり切った定型的な画面となりますが、実運用で使えるものを作るとなると意外に手間がかかります。Djangoはこのバックエンド用画面を簡単に提供することを目的としています。

　管理インターフェイスはを実運用でも十分に使用できるレベルのものであり、カスタマイズも容易です。Ruby on Railsのscaffoldとは違い、ソースコードを自動生成せず、モデル定義から動的に画面を生成するのも特徴の1つです。図3が管理インターフェイスのログイン後トップメニュー画面イメージです。