私はこれについてグーグルで調べましたが、Djangoが「アプリ」と定義しているものに関連してまだ問題があります.
メイン プロジェクトのモデルを使用している場合でも、サイト内の機能ごとに新しいアプリを作成する必要がありますか?
新しいアプリをいつ分割するか、いつ機能を「メイン プロジェクト」または他のアプリと一緒に保持するかについて、経験則はありますか?
James Bennett は、 Django で再利用可能なアプリを整理する方法についての素晴らしいスライド セットを持っています。
私は、Django アプリケーションを「アプリケーション」としてではなく、再利用可能なモジュールまたはコンポーネントとして考えることを好みます。
これにより、特定の機能をカプセル化して相互に分離し、特定の「アプリ」をコミュニティ全体と共有することにした場合の再利用性と保守性を向上させることができます。
私の一般的なアプローチは、特定の機能または機能セットを「アプリ」にまとめて公開することです。ここで難しいのは、各バケットの大きさを把握することです。
私が使用する良いトリックは、自分のアプリが公開された場合にどのように使用されるかを想像することです。これにより、バケツを縮小し、その「目的」をより明確に定義することがよくあります。
以下は、2008 年 9 月 6 日に更新されたプレゼンテーションです。
DjangoCon 2008: 再利用可能なアプリ @7:53
スライドより抜粋
これは独自のアプリケーションである必要がありますか?
- アプリのフォーカスとはまったく関係ありませんか?
- それは私がやっていることと直交していますか?
- 他のサイトでも同様の機能が必要ですか?
それらのいずれかが「はい」の場合? 次に、別のアプリケーションに分割することをお勧めします。
私は、論理的に分離されたモデル セットごとに新しいアプリケーションを作成する傾向があります。例えば:
私が従うルールは、別のプロジェクトで機能を再利用したい場合は、新しいアプリでなければならないということです.
プロジェクトのモデルを深く理解する必要がある場合は、モデルに固執する方がおそらくまとまりがあります。
「アプリ」はさまざまなものである可能性がありますが、それはすべて実際に味わうことになります。たとえば、ブログを作成しているとします。アプリはブログ全体にすることも、「admin」アプリ、すべてのパブリックビュー用の「site」アプリ、「rss」アプリ、「services」アプリを使用して、開発者がブログとやり取りできるようにすることもできます。独自の方法など。
私は個人的にブログ自体をアプリにし、その中の機能を分解します。その後、ブログは他のWebサイトでかなり簡単に再利用できます。
Djangoの良いところは、ディレクトリツリーの任意のレベルにあるmodels.pyファイルをDjangoモデルを含むファイルとして認識することです。したがって、「アプリ」自体の中で機能をより小さな「サブアプリ」に分割しても、それ以上の困難はありません。