0

私は現在、Django で既存の PHP CodeIgniter プロジェクトを構築することについてブレインストーミングを行っています。私はすでにドキュメンテーションを少し調べて、それがどのように機能するかをテストするためにいくつかのオンラインチュートリアルを行い、それに本当に魅了されました.

私が現在直面している理論上の設計上の問題は、私が念頭に置いていることです。アプリは相互に依存しますが、Django のドキュメント自体にはApps be pluggableと記載されています。

問題は、色、グループ、モデル (外部キー関係) などのさまざまなサブプロパティを持つ製品アプリがあることです。今、請求書アプリの使い方を考え始めましたが、請求書アプリには製品アプリの製品が必要であることにすぐに気付きました。

他の人が Django プロジェクトでこれをどのように行っているのだろうか? アプリケーション全体 (製品、請求書、注文、配送、電子メールなど) の設計方法と、それらを個別にリンクする方法を再考する必要がありますか?

Invoices AppにはProducts App を初期化する必要があることを Django に伝えますか?それとも、 ERP App のようにすべてのパーツを独自のモデルとして格納する状況を完全に改造しますか?

最終的には、フロント オフィスも Django (Webshop) に変換し、バック オフィス (ERP) 製品にアクセスできるようにしたいと考えています。また、それをどのように組み込むかについても考えています。

4

1 に答える 1

2

あなたが何を求めているのかよくわかりませんが、苦労して学んだ教訓に基づいたヒントをいくつか紹介します。

  1. アプリは 1 つのことだけを行う必要があります。文中に 3 つまたは 4 つの「and」がないとアプリの機能を説明できない場合は、アプリを再考する必要があります。

  2. モデルはアプリに関連付けられています。ただし、これはアプリ A のモデルをアプリ B で使用できないという意味ではありません。モデル自体はアプリではありません。「サブプロパティが異なる製品アプリ」とは言えません。

  3. 必要に応じて、モデルはあるがビューがないアプリを作成できます。アプリがビューを提供しなければならないという要件はありません。

  4. ビューをシンプルに保ち、モデルをリッチに保ちます。アプリケーションには、ヘルパーとして機能する多くのユーティリティ スクリプトが含まれる可能性がありますが、これは問題なく推奨されます。ビューに多くの複雑なロジックは必要ありません。また、テンプレートに多くのロジックは必要ありません。

django のドキュメントに、アプリはプラグイン可能であると記載されている場合、それは、アプリケーションがスタンドアロンであるべきであることを意味します。必要なすべての依存関係 (テンプレート、URL、ビュー、モデル) をアプリと一緒に含めて、アプリを公開し、ユーザーが最小限の影響でアプリをダウンロードして統合できるようにする必要があります。1.5 のリリースでは、チュートリアルに再利用可能なアプリの作成方法に関する新しいセクションが追加され、より多くの洞察が得られるはずです。

優れたプラグイン可能なアプリとは、問題を解決するために簡単に「連鎖」できるアプリであると私は主張します。

于 2013-05-12T17:14:31.740 に答える