web-dev-qa-db-ja.com

Django：「プロジェクト」と「アプリ」

Djangoを使用してビルドする準備ができているかなり複雑な「製品」があります。 Djangoでの具体的な意味が明確ではないため、このコンテキストでは「プロジェクト」と「アプリケーション」という用語の使用を避けます。

プロジェクトには多くのアプリを含めることができます。アプリは多くのプロジェクトで共有できます。いいよ.

私はブログやフォーラムを再発明しているわけではありません-私の製品のどの部分もどのような状況でも再利用可能ではありません。直感的には、これを「アプリケーション」と呼びます。その後、すべての作業を単一の「アプリ」フォルダーで行いますか？

もしそうなら ... Djangoのproject.app名前空間の観点から、私の傾向はmyproduct.myproductを使用することですが、もちろんこれは許可されていません（しかし、私が構築しているアプリケーション私のプロジェクトであり、私のプロジェクトはアプリケーションです！）。したがって、おそらく「重要な」モデルごとに1つのアプリを構築することでDjangoにアプローチすることになっていると思われますが、スキーマの境界をどこに分けて分割するかわかりません。アプリ-比較的複雑な関係を持つ多くのモデルがあります。

私はこれに共通の解決策があることを望んでいます...

pythondjangonamespacesproject-organization
193
Dolph

myproduct.myproductの使用を止めることは何ですか？これを達成するために必要なことは、大まかにこれを行うことから成ります：

Django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

等々。 views.pyをviews.pyと呼ぶ必要がないと言ったら助けになりますか？ pythonパスで、処理される関数（通常はpackage.package.views.function_name）に名前を付けることができます。そのような単純な。この「プロジェクト」/「アプリ」はすべてpythonパッケージです。

さて、あなたはそれをどうやってするのですか？むしろ、どうすればいいですか？マークアップエディターなどの重要な再利用可能な機能を作成する場合は、widgets.py、fields.py、context_processors.pyなどを含む「トップレベルアプリ」を作成します。インポートしたいすべてのもの。

同様に、ブログのようなものをインストール全体で非常に一般的な形式で作成できる場合は、独自のテンプレート、静的コンテンツフォルダーなどを使用してアプリでラップし、Djangoのインスタンスを構成できますそのアプリのコンテンツを使用するプロジェクト。

あなたがこれをしなければならないという厳しい規則はありませんが、それはフレームワークの目標の一つです。テンプレートが含まれるすべてのものが、いくつかの共通のベースからインクルードできるという事実は、ブログが他のセットアップにぴったりとフィットすることを意味します。

ただし、実際の懸念に対処するために、はい、トップレベルのプロジェクトフォルダーで作業できないということはありません。 それがアプリの機能です。本当にしたい場合はそれを行うことができます。しかし、私はいくつかの理由でそうしない傾向があります。

  • Djangoのデフォルトのセットアップではできません。
  • 多くの場合、メインアプリを作成するため、通常websiteと呼ばれるアプリを作成します。ただし、後日、このサイト専用のオリジナル機能を開発したいと思うかもしれません。それを取り外し可能にするという観点から（私がするかどうかに関係なく）、私は別のディレクトリを作成する傾向があります。これは、グローバルなurls.pyフォルダーから適切なURLを複雑に削除するのではなく、そのパッケージを構成からリンク解除してフォルダーを削除するだけで、上記の機能をドロップできることも意味します。
  • 非常に頻繁に、私が何かを独立させたいときでさえ、それは私がそれを世話する/それを独立させる間、どこかに住む必要がある。基本的には上記のケースですが、一般的なものを作成するつもりです。
  • 私のトップレベルのフォルダーには、wsgiスクリプト、sqlスクリプトなどを含むがこれらに限定されない他のいくつかのものが含まれていることがよくあります。
  • Djangoの 管理拡張機能 はサブディレクトリに依存しています。したがって、パッケージに適切な名前を付けることは理にかなっています。

要するに、慣習がある理由は他の慣習と同じです-あなたのプロジェクトで作業している他の人に来るときに役立ちます。 fields.pyが表示された場合、すぐにDjangoのフィールドをサブクラス化するコードを期待しますが、inputtypes.pyが表示された場合、それを見なければ意味がわかりません。

56
user257111

startprojectとstartappを使用して卒業したら、同じPythonパッケージで「プロジェクト」と「アプリ」を組み合わせることを止めることはできません。プロジェクトは実際にはsettingsモジュールにすぎず、アプリは実際にはmodelsモジュールにすぎません。他のすべてはオプションです。

小規模なサイトの場合、次のようなものを使用することはまったく合理的です。

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py
89
claymation

「私のアプリケーションは何をしますか？」という質問に答えてみてください。 1つの文で答えられない場合は、より簡潔なロジックで複数のアプリに分割できます。

私はDjangoを使い始めてすぐにこの考えを読みましたが、この質問を頻繁に自分自身に尋ねることができ、助けになります。

アプリは再利用可能である必要はありません。お互いに依存できますが、1つのことを行う必要があります。

69
Ski

Djangoアプリケーションおよびプロジェクトに関する次のブログ投稿が非常に役立つことがわかりました。

原則として、製品のソースコードを整理するためのDjangoには多くの自由があります。

15
JooMing

もしそうなら... Djangoのproject.app名前空間の観点から、私の傾向はmyproduct.myproductを使用することですが、もちろんこれは許可されていません

許可されていないようなものはありません。そのプロジェクト、誰もあなたを制限していません。適切な名前を付けることをお勧めします。

私の製品のどの部分も、どのような状況でも再利用可能ではありません。直感的には、これを「アプリケーション」と呼びます。その後、すべての作業を単一の「アプリ」フォルダーで行いますか？

一般的なDjangoプロジェクトには、すべてのプロジェクトで実際に使用される多くのアプリ（contribアプリ）があります。

プロジェクトが1つのタスクのみを実行し、1つのアプリのみを持っているとしましょう（プロジェクトがその周りを回っており、ほとんどプラグインできないため、mainと名付けます）。このプロジェクトでも、他のアプリを一般的に使用しています。

プロジェクトが1つのアプリ（INSTALLED_APPS='myproduct'）のみを使用していると言う場合、projectを使用してプロジェクトをproject.appとして定義すると、いくつかの点を考慮する必要があります。

  • プロジェクト内のアプリ以外のコードが処理するものは他にもたくさんあります（ベースの静的ファイル、ベースのテンプレート、設定、つまりベースを提供します）。
  • 一般的なproject.appアプローチでは、DjangoはモデルからSQLスキーマを自動的に定義します。
  • プロジェクトは、従来のアプローチで構築するのがはるかに簡単になります。
  • 必要に応じて、URL、ビュー、およびその他のファイルにいくつかの異なる名前を定義できますが、必要はありません。
  • 将来的には、従来のDjangoプロジェクトでは本当に簡単になるアプリケーションを追加する必要があるかもしれません。

アプリで行われているほとんどの作業に関する限り、ほとんどのDjangoプロジェクトに当てはまると思います。

8
crodjer

ここDjango作成者はその違いを自分自身で指摘しています 。他のプロジェクトで再利用可能でなければならないアプリについて考えることはgood。 DjangoのAppsについて考える良い方法は、最新のWebアプリケーションを提供します。

大きなdynamicJavaScriptに基づくWebアプリを作成していると想像してください。

次に、Djangoという名前のアプリを作成できます。たとえば、「FrontEnd」という名前のアプリです。シンアプリでは、コンテンツを表示します。

次に、バックエンドアプリを作成します。たとえば、ユーザーのコメントを保存する「Comments」という名前のアプリ。また、「コメント」アプリには何も表示されません。 AJAXあなたのdynamicJSウェブサイト。

このようにして、「コメント」アプリをいつでも再利用できます。プロジェクト全体のソースを開かずに、オープンソースにすることができます。そして、プロジェクトのクリーンlogicを保ちます。

1
Qback