Django で「アプリ」が何を意味するかについて多くの混乱があることに気付きました。これは、ドキュメントがこの抽象的な概念をより抽象化して説明しているだけであるためです。( http://docs.djangoproject.com/en/dev/intro/tutorial01/ )
アプリ化すべき具体例は?
Django で「アプリ」が何を意味するかについて多くの混乱があることに気付きました。これは、ドキュメントがこの抽象的な概念をより抽象化して説明しているだけであるためです。( http://docs.djangoproject.com/en/dev/intro/tutorial01/ )
アプリ化すべき具体例は?
Django の「アプリ」は、サイトの高レベルの機能だと思います。フォーラム、ライフ チャット、FAQ、およびイメージ ギャラリーを提供するサイトがあるとします。これら 4 つの機能ごとに個別の Django アプリを作成します。各アプリは持つことができますが、必ずしも持つ必要はありません。それは、すべて密接に関連し、単一の高レベルの目的を果たす独自のモデル、ビュー、テンプレート (および場合によってはミドルウェアやその他のもの) です。
それが私がそれを説明する方法です。
の全体django.contrib
。各アプリの機能の説明については、http://docs.djangoproject.com/en/dev/ref/contrib/を参照してください。
基本的に、プロジェクトに依存しないユーティリティに要約できる機能のセットは、再利用可能なアプリになる必要があります。
現在、Python/Django を使用して分散アプリケーションを構築しています。特定のサーバーは、機能のコア セットに加えて、その状況に応じた特定の機能を参照する必要があります。完全なモデル ビュー テンプレート システムが必要な部分もあれば、モデルを共有するだけでよい部分もあります。アプリケーションの一部はインメモリ データベースを使用し、アプリケーションの残りの部分はエンタープライズ クラスのデータベースを使用します。
settings.py
このアプリケーションを、「スマート」とurls.py
スクリプトを使用してオンまたはオフにできる「アプリ」のセットとして構成することにしました。「コア」アプリには、アプリケーション全体に共通のモデルのみがあります (ただし、ビューやテンプレートはありません)。「webcore」アプリは、Web UI を提供するすべてのアプリに共通するビューとテンプレートを追加します。他のアプリには、独自のモデルに加えて、適切なビューとテンプレートがあります。一部のアプリはバックグラウンド サービスのみを実装するため、ビューやテンプレートは必要ありません。
settings.py
およびスクリプトで複数のアプリを組み合わせることurls.py
で、アプリケーション全体の複雑さに対処する必要なく、アプリケーションの小さな部分をビルドしてテストできます。アプリケーションの一部を複数のサーバーに配布することもできます (スケーリングまたは固有のリソースを利用するため)。単一の「アプリ」を使用してこのアプリケーションを構築していた場合、多くの柔軟性が失われます。
James Bennett によるこの講演は、あなたのすべての質問に答えるはずです :)