[解決済み】Django。"プロジェクト "と "アプリ "の違い

質問

私は、Django を使って構築する準備をしている、かなり複雑な "product" があります。Django における具体的な意味がよくわからないので、この文脈では "project" と "application" という用語は使わないことにします。

プロジェクトは多くのアプリを持つことができます。アプリは多くのプロジェクト間で共有することができます。結構です。

私はブログやフォーラムを再発明しているわけではありません。私の製品のどの部分も、どんな文脈でも再利用可能だとは思えません。直感的に、私はこれを1つのquot;application.quotと呼ぶでしょう。それから、私はすべての作業を1つのquot;app"フォルダで行うのでしょうか？

もしそうなら ... Django の観点では project.app 名前空間を使用する場合、私の希望としては myproduct.myproduct しかし、もちろんこれは許されません（しかし、私が作っているアプリケーションは私のプロジェクトであり、私のプロジェクトはアプリケーションなのです！）。したがって、おそらく私は、 "significant" モデルごとに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） を指定すれば、それが処理されます。単純なことです。この "project"/"app" はすべて Python パッケージに過ぎません。

さて、どうすればいいのでしょうか？というか、どうすればいいんだろう？例えば、マークアップエディターのような再利用可能な機能の重要な部分を作成する場合、トップレベルのアプリを作成します。 widgets.py , fields.py , context_processors.py などなど、インポートしたいものばかりです。

同様に、もしあなたがブログのようなものを、インストールに関係なく汎用的なフォーマットで作成できるなら、それを独自のテンプレートや静的コンテンツフォルダなどを持つアプリでラップし、そのアプリのコンテンツを使用するために django プロジェクトのインスタンスを構成することができます。

こうしなければならないという厳密なルールはありませんが、フレームワークの目標の1つです。テンプレートも含めて、すべてが共通のベースからインクルードできるということは、あなたのブログは、それ自身の部分の世話をするだけで、他のどんなセットアップにもぴったりとフィットするはずです。

しかし、実際のところ、プロジェクト・フォルダーの最上位で作業できないということはないのです。
それは、アプリの仕事 本当にやりたければやればいいんです。しかし、私はいくつかの理由から、そうしない傾向にあります。

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

要するに、規約がある理由は他の規約と同じで、他の人があなたのプロジェクトで作業するときに役立つからです。もし私が fields.py 私はすぐにその中のコードが django のフィールドをサブクラス化することを期待しますが、一方で inputtypes.py 見ないと意味がよくわからないかもしれませんね。