#【概要】
Djangoの構造についてメモ
色んな角度からDjangoの構造を捉え、理想的なプロジェクトを作るための備忘録を記述してみます。

#【アーキテクチャ】
URLConf == URLパターンとviewのマッチングを保持するモジュール
URLディスパッチャ == URLConfに従いリクエストしたURLに応じたビューを呼ぶ
View == バックエンド、ModelやTemplateと連携しレスポンスを作成する。
Model == モデルクラスとテーブルの紐づけを行う。
Template == フロントエンド、html/js/cssを用いてGUIを作成、表示する。
form == ユーザからの入力オブジェクトを扱う。
middleware == リクエストの前処理とレスポンスの後処理を行う。

#【MTVフレームワーク】
####Djangoを構成する要素
・Model(DB)
・View
・Template
一般的なWebAPPフレームワークとされるMVCと大きく変わらない構造。
MVCのViewはMTVにおけるviewとtemplateが、MCVのControllerはMTVにおけるURLディスパッチャが役割を担っている。

#【プロジェクトの構造】
Djangoのディレクトリ・ファイルの構造は、まずプロジェクトとアプリケーションという単位で分けられている。
プロジェクトはすべてのディレクトリを内包したディレクトリ。
アプリケーションはページ、機能ごとに分割されたパッケージを内包するディレクトリ。

実装の流れとしては、最初にプロジェクトを作成し、適宜アプリケーションが増えていく。
アプリケーションは入れ替えができるように、他アプリケーションに依存しないような構造で制作するほうが良い。
Modelの構造も、他アプリケーションの外部キーで雁字搦めになる恐れがあるため可能な限り"粗"なつくりにする。

#【一般的なプロジェクト・アプリケーションの構造】
プロジェクト名と同じ名前の設定ディレクトリと、アプリケーションごとにMTVが存在し、Templateの中に画像やjsライブラリなどの静的ファイル(static)があるような構造。

####このディレクトリ構造を作成したときに感じた問題点
・templateやstaticが各アプリケーションごとにバラバラに管理されてしまい共通で使用する部分を逐一作る必要があった。

#【管理コストの低いディレクトリ構造の考察】
####・設定ディレクトリにtemplatesを作成し、base.htmlを作成してアプリケーションごとに継承する。
例えばqiitaのページを見てもわかる通り、どのページにも共通するデザインと機能をbase.htmlに実装し、他のアプリケーションからhtmlを継承すれば管理、実装コストが下がる。

####・設定ディレクトリにstaticを作成
上記のbase.htmlに必須となるライブラリとビジュアルファイルなどを格納し、継承元となるbase.htmlがロードする。管理工数は削減できるが不要な読み込みなどを行う可能性がある。

####・js/cssはhtmlとは別に作成し、staticへ格納
htmlのコードが長くなりすぎるため、jsとcssは別ファイルで実装、管理する。
jsとcssは設定ディレクトリ/static/アプリケーション名/js(css)のなかにファイルを格納する。
ファイルを分けた時、バックエンドとのデータのやり取りの書き方が、まとめてある時と少し違うため注意が必要。

####・メニューの構造のデータなどはコードに書かずに外部から読み込む
WebAPPに限らず、どのようなプロジェクトでも適用するべき考え方で、パラメータ関係は、外部ファイルで管理する。

#まとめ
Djangoの経験を1年ほど積んでプロジェクトの構造について思うことを記述した。
ネット上の記事、書籍を拝見しいるとプロジェクトの構造はある範囲のルールの中で、各々が自由に構築しているように見受けられた。

####総括
・リサイクルできるとこはリサイクル
・外部ファイル、ライブラリは設定ディレクトリで一括管理
・フロントエンドのパーツ(html/js/css)は分けて実装
・アプリケーションごとに分割管理するのはMVCのみ

####注意点
継承を多用したり、外部ファイルやライブラリの管理場所を一カ所に設定するとプロジェクトの全体の構造をわかりにくくする一因となる。他人が実装しづらかったり、ファイルを既定の場所に置かなかったりトラブルが起きると予想されるため、プロジェクトのアーキテクチャのルールは必ず明記・共有したほうが良い。