Djangoの基本的な設計原理のApp

基本原理

各アプリケーションは、ただ一つのことだけを行う必要があります。その機能は、プロセスが1つ以下で説明されている場合、簡単な文が明確に記述することができます使用する必要がある「と」、スプリットへの必要性を、このアプリのビット大を意味するかもしれません。

ジェームズ・ベネット：
良いDjangoのアプリを作成し、維持の芸術は、それはダグラス・マクロイに応じて切り捨てUNIX哲学に従うべきであるということです。「一つのことをして、それをうまくやるの書き込みプログラム」。

どのようにDjangoのアプリの命名

1. 以下のような言葉を使用してみてください動物、ブログ、夢、世論調査。プロジェクトのシンプルで明確なセマンティック名を維持しやすいです。

2. 適切な場合には、メインデータモデルの名前が複数形で内部アプリケーション、アプリケーション名を参照することができます。

3. することができ、このようなブログのURLと、URLの形式を命名を検討http://www.example.com/weblog/、あなたが考えることができますアプリの名前のウェブログではなく、ブログや記事を。

4. 等の小さな印刷文字、数字、との完全な名前は、他の文字は、必要に応じて、下線することができ、使用しないでください_、しかし、使用しないようにしてみてください。

ためらいあなたは小さなプログラムアプリケーションを使用する場合

アプリのデザインやスプリット機能は芸術ではなく、技術です。将来の再編成を分割する必要があるかもしれませんので。

アプリは小さなアプリのApp多数の保守が容易に比べて十分に小さいを作ってみます。

どちらのモジュールは、Appがありますか？

共通モジュール：

これらのモジュールは、Djangoのアプリケーションの99％で見ることができます。

# Common modules
scoops/
    __init__.py
    admin.py
    forms.py
    management/
    migrations/
    models.py
    templatetags/
    tests/
    urls.py
    views.py

あまり一般的でモジュール

# uncommon modules
scoops/
    behaviors.py
    constants.py
    context_processors.py
    decorators.py
    db/
    exceptions
    fields.py
    factories.py
    helpers.py
    managers.py
    middleware.py
    signals.py
    utils.py
    viewmixins.py

各モジュールの機能の説明を次のように

モジュールは|機能説明
-------------- |
constants.py |アプリケーションレベルの設定は、過度のApp設定値場合は、ファイル内の別々でなければなりません
decorators.pyのApp |デコレータ
のdb /バッグ|カスタマイズされたデータモデル項目と他のデータベース関連のコンポーネントは
fields.py |配置カスタムデータモデル項目、そうでない場合より、データベース関連のコンポーネントは、唯一のDBパッケージ作成せずに、ファイルに配置することができ
factories.pyを |テストデータファクトリ関数生成
helpers.pyをから| のviews.pyとmodels.py機能機能アクセシビリティの一部を抽出し
utils.pyを有する| helpers.py
managers.py場合| models.pyが大きい場合、それはカスタマイズすることができますモデル管理者は、抽出された
signals.pyをカスタム信号|
viewmixins.pyをから| のviews.pyミックスインで抽出されました

参考文献：Djangoの二つのスクープ：Djangoの1.8のベストプラクティス