94

上司からの指示:「 にロジックを入れるのは避けたいですmodels.py。今後は、データベースにアクセスするためのクラスとしてのみ使用し、すべてのロジックをモデル クラスを使用する外部クラスに保持するか、それらをラップします。」

これは間違った方法だと感じています。ファイルを小さく保つためだけにモデルからロジックを除外するのは悪い考えだと思います。ロジックがモデル内で最適である場合、ファイル サイズに関係なく、実際にそこに移動する必要があります。

インクルードを使用する簡単な方法はありますか？models.pyPHP で言えば、他の場所からのモデル クラスを include() することをスーパーバイザーに提案したいと思います。概念的には、これにより、モデルに必要なすべてのロジックを持たせることができますが、ファイルの数を増やすことでファイル サイズを抑えることができます (競合などのリビジョン管理の問題が少なくなります)。

では、models.py ファイルからモデル クラスを削除する簡単な方法はありますが、モデルはすべての Django ツールで動作しますか? または、「大きな」models.pyファイルの一般的な問題に対する、まったく異なるがエレガントな解決策はありますか? 任意の入力をいただければ幸いです。

4

3 に答える 3

113

モデル クラスがモデルを操作するメソッドを含むのは自然なことです。私が Book モデルを持っていて、 method を持っている場合、それが属している場所です.メソッドが実際に本質的に他のパッケージに属していない限り、book.get_noun_count()" "と書く必要はありません. get_noun_count(book)(たとえば、Amazon の API に " get_amazon_product_id(book)" でアクセスするためのパッケージがあるとします。)

Django のドキュメンテーションでモデルを 1 つのファイルに入れることを提案されたとき、私はうんざりしました。最初から数分かけて、モデルを適切なサブパッケージに分割する方法を見つけました。

site/models/__init__.py
site/models/book.py

__init__.py次のようになります。

from .book import Book

そのため、「from site.models import Book」と書くことができます。

以下は、Django 1.7 より前のバージョンにのみ必要です 。https://code.djangoproject.com/ticket/3591を参照してください。

唯一の秘訣は、Django のバグにより、各モデルのアプリケーションを明示的に設定する必要があることです。アプリケーション名がモデル パスの最後から 3 番目のエントリであると想定します。「site.models.Book」の結果は「site」になります。これは正しいです。「site.models.book.Book」は、アプリケーション名が「models」であると認識させます。これは、Django 側の非常に厄介なハックです。おそらく、インストールされているアプリケーションのリストでプレフィックスの一致を検索する必要があります。

class Book(models.Model):
    class Meta: app_label = "site"

おそらくこれを一般化するために基本クラスまたはメタクラスを使用できますが、私はまだそれを気にしていません。

于 2009-07-21T18:02:38.617 に答える
65

Django は、1 つの大きなアプリケーションではなく、多数の小さなアプリケーションを構築できるように設計されています。

すべての大きなアプリケーションの中には、無料にするのに苦労している多くの小さなアプリケーションがあります。

自分models.pyが大きいと感じたら、やりすぎです。止まる。リラックス。分解します。

より小さく、潜在的に再利用可能な小さなアプリケーション コンポーネント、または断片を見つけます。実際に再利用する必要はありません。それらは潜在的に再利用可能であると考えてください。

アップグレード パスを検討し、いつか置き換える可能性のあるアプリケーションを分解します。それらを実際に置き換える必要はありませんが、将来より優れたものに置き換えられる可能性があるプログラミングのスタンドアロンの「モジュール」と見なすことができます。

約 12 個のアプリケーションがあり、それぞれmodel.pyが約 400 行のコードしかありません。それらはすべて、約半ダース未満の個別のクラス定義に重点を置いています。(これらは厳密な制限ではなく、コードに関する観察事項です。)

私たちは早く、そして頻繁に分解します。

于 2009-07-21T17:32:43.110 に答える
6

あなたが抱えている可能性のある多くの問題のうち、どれが問題なのか、私にはよくわかりません。答えのいくつかの可能性は次のとおりです。

  • 同じファイル内の複数のモデル

    それらを別々のファイルに入れます。依存関係がある場合は、インポートを使用して追加のモデルを取り込みます。

  • models.py の余分なロジック / ユーティリティ関数

    余分なロジックを別のファイルに入れます。

  • データベースからいくつかのモデル インスタンスを選択するための静的メソッド

    別のファイルに新しいマネージャーを作成します。

  • 明らかにモデルに関連するメソッド

    save、__unicode__、および get_absolute_url が例です。

于 2009-07-21T18:42:12.033 に答える