2

プロジェクトの機能をさまざまなアプリに分割する方法を判断するのに苦労しています。

簡単な例: メンバーがいて、メンバーはもう 1 つサービスを受けることができます。サービスは、アップグレード、ダウングレード、他のサービスの追加、キャンセルが可能です。(これは非常に単純化されています。実際に単純な場合は、事前に作成されたソリューションを使用します)

私が最初に考えたのは、これを「メンバー」アプリケーションにし、次に更新、アップグレード/ダウングレード、およびキャンセルを処理する「サービス」アプリにすることでした。

それで、更新アプリ、アップグレード/ダウングレード アプリ、およびキャンセル アプリを作成する必要があると考えました。ただし、これらのアプリはすべて、DB (メンバーとサービス) 内の同じテーブルに依存します。アプリケーションは互いに独立しているべきだと思っていました。他のアプリ モデルに大きく依存するアプリケーションを作成しても問題ありませんか?

同様に、非常に多くのアプリでサービス テーブルを使用する場合、モデルを格納してサービス テーブルを作成するには、どのアプリケーションを使用すればよいでしょうか?

4

2 に答える 2

3

最初に考えたのは正しいと思います。すべてを複数のアプリに分割してもそれほど多くの利点は得られません。逆に、面倒で管理が難しくなる可能性があります。

Django のやり方は、多くのモデルに依存しています。各オブジェクトは、データ モデルのエンティティにマップされます。あなたのアプリは、ほとんどの場合、そのようなデータ モデルに関連して編成されています。したがって、異なる部分を持つエンティティ (サービス) がある場合は、それらの部分を同じものの一部として理解することをお勧めします。もう一方のエンティティ (メンバー) は、別のものであるため、別のものである必要があります。

異なるアプリからモデルをインポートしてもペナルティはありません。とにかく最も重要なことは、一貫性のあるデータモデルを構築することです。

于 2012-11-15T19:54:31.907 に答える
0

アプリのポイントは、サードパーティがアドオンとして再利用することを意図したコードを許可することです。プロジェクトをアプリに分割したとしても、あまり分割したくないでしょう。

于 2012-11-15T19:56:58.820 に答える