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

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

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

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

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

これに対する一般的な解決策があることを願っています...

あなたが使用を止めることは何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プロジェクトのインスタンスを設定できますアプリのコンテンツ。

これを実行しなければならないという明確な規則はありませんが、これはフレームワークの目標の1つです。すべてのテンプレートが含まれているため、共通のベースから含めることができるという事実は、ブログを他の設定にぴったりと合わせる必要があることを意味します。

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

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

要するに、規約がある理由は他の規約と同じです-それはあなたのプロジェクトで働いている他の人になると助けになります。私が見た場合fields.py、私はすぐに私が見た場合のに対して、Djangoのフィールドをサブクラス化することで、コードを期待してinputtypes.py、私はそれを見ずに何を意味その上それほど明確ではないかもしれません。

startprojectandの使用startappを終えたら、同じPythonパッケージで「プロジェクト」と「アプリ」を組み合わせるのを妨げるものは何もありません。プロジェクトは実際にはsettingsモジュールにすぎず、アプリは実際にはmodelsモジュールにすぎません。それ以外はすべてオプションです。

小さなサイトの場合、次のようなものを用意することは完全に合理的です。

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

「私のアプリケーションは何をしますか？」という質問に答えてみてください。単一の文で答えることができない場合は、より明確なロジックで複数のアプリに分割することができます。

私はジャンゴを使い始めた直後にどこかでこの考えを読みました。私は自分自身にこの質問を頻繁に尋ね、それが私を助けてくれることに気づきました。

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

djangoのアプリケーションとプロジェクトについて、次のブログ投稿が非常に役立つことがわかりました。

• http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
• http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

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

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

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

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

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

あなたのプロジェクトが1つのタスクしか実行せず、1つのアプリしか持っていないとしましょう（mainプロジェクトはそれを中心に展開し、ほとんどプラグインできないので、名前を付けます）。このプロジェクトでも、一般的に他のいくつかのアプリをまだ使用しています。

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

• プロジェクト内のアプリ以外のコードが処理する他の多くのものがあります（基本の静的ファイル、基本のテンプレート、設定....つまり、基本を提供します）。
• 一般的なproject.appアプローチでは、djangoはモデルからSQLスキーマを自動的に定義します。
• プロジェクトは、従来のアプローチで構築する方がはるかに簡単です。
• 必要に応じて、URL、ビュー、その他のファイルにいくつかの異なる名前を定義することができますが、私はその必要性を理解していません。
• 将来的には、従来のdjangoプロジェクトでは非常に簡単になるいくつかのアプリケーションを追加する必要があります。そうしないと、同等またはそれ以上に困難で面倒な作業になる可能性があります。

アプリで行われているほとんどの作業に関しては、ほとんどのdjangoプロジェクトがそうです。

ここで、Django作成者はその違いを自ら指摘します。アプリは他のプロジェクトで再利用できるようにする必要があるので、アプリについて考えるのは良いことだと思います。また、Djangoのアプリについて考える良い方法は、最新のウェブアプリケーションを提供することです。

JavaScriptに基づいて大きな動的 Webアプリを作成しているとしましょう。

次に、「FrontEnd」などの名前のdjangoアプリを作成できます<-thinsアプリでは、コンテンツを表示します。

次に、いくつかのバックエンドアプリを作成します。たとえば、ユーザーのコメントを保存する「コメント」という名前のアプリ。また、「コメント」アプリ自体は何も表示しません。これは、動的 JS Webサイトの AJAXリクエスト用の単なるAPIになります。

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