Flaskアプリケーションをどの様な構成にするかはあなたが自由に決めることが出来ます。 これは私がFlaskを好む理由の一つですが、ソースコードの構成について幾つか考えなければならないことがあります。 Flaskではアプリケーション全体を1つのソースファイルに収めることもできますし、複数のパッケージに分割することも可能です。 ここでは、Flaskアプリケーション開発を容易にするための構成パターンを幾つか紹介します。
それではまずこの章で登場する幾つかの用語を定義します。
レポジトリ : これはプロジェクトの起点ディレクトリです。 これは本来バージョン管理システムで利用される用語ですが、この章ではプロジェクトの起点ディレクトリという意味で利用します。 アプリケーションを動作させる際にこのディレクトリの全ては必要ありません。
パッケージ : これはアプリケーションコードを含むPythonパッケージです。 この章ではアプリケーションをパッケージとして構成する方法を詳しく説明していきますが、今の所パッケージとはレポジトリ下にあるサブディレクトリだと思って構いません。
モジュール : モジュールは他のPythonファイルからインポート可能な単一のPythonファイルのことです。そして複数のモジュールをまとめた物がパッケージです。
注記
-
Pythonモジュールについてはこちらを参照してください。 Python tutorial
-
同じページのこの節も参考になります。 section on packages.
Flaskのサンプルコードを見ていくと、全てのソースコードをapp.pyという様な単一ファイルに収めている例が多いことに気がつくでしょう。 これは処理するURLルーティングが数個で、ソースコードが数百行以下の早急なプロジェクトで非常に役立ちます。
app.py
config.py
requirements.txt
static/
templates/
アプリケーションのロジックは上記の例ではapp.pyに記述します。
もう少し複雑なプロジェクトである場合、単一ファイルでは乱雑になってしまいます。 その様な場合モデルやフォームのためにクラスを定義する必要がありますし、URLルーティングの処理と設定ファイルも分離した方が良いでしょう。 単一ファイルでの開発には限界があります。 複雑なプロジェクトの場合、アプリケーションのコンポーネントとして分離した内部モジュールをパッケージにまとめることが可能です。
config.py
requirements.txt
run.py
instance/
config.py
yourapp/
__init__.py
views.py
models.py
forms.py
static/
templates/
上記に記載したディレクトリ構成は、アプリケーションに複数のコンポーネントを組み込むことが可能です。 モデル用のクラスはmodels.pyに、URLルーティングはviews.py、フォームはforms.pyに定義されます。(フォームについては後の章で詳しく説明します)
以下はFlaskアプリケーションでよく見るファイルの一覧です。 既存のプロジェクトのファイルと重複してしまうかもしれませんが、これらは多くのFlaskアプリケーションで共通して使われているファイル名です。
run.py : これは開発用サーバーを起動するスクリプトです。 これを実行すると、パッケージをコピーしてアプリケーションを実行します。 これは開発環境のみで利用され、本番環境では必要ありません。
requirements.txt : これはアプリケーションが依存しているPythonパッケージの一覧です。開発環境と本番環境でファイルを別けているかもしれません。
config.py : このファイルにはアプリケーションが必要とする設定情報を記述します。
/instance/config.py
: このファイルには設定情報を記述し、バージョン管理を行いません。
ここにはAPIキーやデータベースへの接続パスワードなどを記述します。
また、このファイルにはアプリケーションインスタンス固有のパラメーターを
記述します。
例えば、config.pyにDEBUG = Falseと設定し、開発環境のinstance/config.pyにはDEBUG = Trueと設定します。
このファイルはconfig.pyの後に読み込まれるのでパラメータは上書きされます。
/yourapp/ : ここにはアプリケーションのパッケージを格納します。
/yourapp/init.py : このファイルではアプリケーションの初期化を行い、様々なコンポーネントを呼び出します。
/yourapp/views.py : ここではURLルーティングの処理を定義します。これは*yourapp/views/*というパッケージでモジュールを分割することもできます。
/yourapp/models.py : ここではアプリケーションのモデルを定義します。views.pyと同じ様に複数のモジュールに分割することができます。
/yourapp/static/ : ここにはCSS、JavaScript、画像などのアプリケーションによって公開される静的ファイルを配置します。 これらのファイルは既定で*example.com/static/*というパスでアクセスできます。
/yourapp/templates/ : ここには、アプリケーションが利用するJinja2テンプレートを配置します。
気がつくと、関連するURLルーティングが増えていることがあります。 私と似た考えの人であればviews.pyを複数のモジュールに分割し、パッケージにまとめたいと思うかもしれません。 この時、ブループリントと呼ばれるアプリケーションの構成要素に分割することが可能です。
ブループリントは自己完結的なアプリケーションの構成要素です。 これはアプリケーションの内部でアプリケーションの様に振る舞います。 例えば、アプリケーションの管理画面、フロントエンド、ユーザーダッシュボー ドという様な複数のブループリントを持つことが可能です。 ブループリントはビューや静的ファイル、テンプレートなどのコンポーネントをひとまとめにし、モデルやフォームはアプリケーション間で共有することができます。 ブループリントを活用したアプリケーション構成については後の章で詳しく説明します。
- 小さいプロジェクトでは、アプリケーションを単一モジュールで実装すると良いでしょう。
- 大きなプロジェクトではモデル・ビュー・フォームなどのコンポーネントをパッケージにまとめることもできます。
- ブループリントはアプリケーションを明確なコンポーネントで構成するための素晴らしい仕組みです。