特定のモデルのに固有のビジネスルールに対応するようにコードを構造化する方法はわかりません。Django-Appを構造化してカスタムビジネスルールをオブジェクトインスタンスに添付する
たとえば、タイプフィールドとchoices=(('I','Individual'),('C','Company))
を持つContactモデルがあるとします。私が持っているモデルのタイプに基づいて、私はカスタムメソッドを持っているかもしれません。
だから、このようなものがいいだろう、大声で思考:
class IndividualContact(Contact):
""" A custom class used for Contact instances with type='I' """
criteria = Q(type='I')
# The goal here is that Contact is now aware of IndividualContact and constructs
# objects accordingly.
Contact.register(IndividualContact)
あるいは:私は私の特別なインスタンス固有のコードのための素敵な家を持っている
class SpecialContact(Contact):
""" A custom class used for the contact with pk=1 """
criteria = Q(pk=1)
た時点で。
私が検討した代替案の1つは、モデル継承を使用し、新しい動作を与えるタイプフィールドのようなものを避けることです。こうすることで、新しいクラスが既存のフレームワークにエレガントにプラグインされ、必要に応じてさまざまなタイプにカスタムフィールドを追加できるようになります。
私の場合、私は「あなたは2つのリスティングと20の写真しか持たない」というような言葉を言うことができるサイトにリソースクレジットシステムを持っています。個々のリソースタイプは配分されますが、さまざまなコンテンツタイプのクレジットを提供する一般的なクレジットテーブルがあります。あなたのリスティングと写真を集計するロジックは、使用しているオブジェクトのタイプによって異なります。
すなわち:
listing_credit = Credit.objects.create(content_type=ContentType.objects.get_for_model(Listing), user=user, credit_amt=2)
# Should subtract **active** listings from current sum total of Listing credits.
listing_credit.credits_remaining()
photo_credit = Credit.objects.create(content_type=ContentType.objects.get_for_model(Photo), user=user, credit_amt=5)
# Photos have no concept of an active status, so we just subtract all photos from the current sum total of Listing credits.
# Also, the Photo might be associated to it's user through a 'created_by' field whereas
# Listing has a user field.
photo_credit.credits_remaining()
私の現在のアプローチは別々のクラスですが、私はその定型だけcredit_ptr_id
とN個別のテーブルを作成するための彼の必要性を軽減したいと思います。
ありがとうございます。これは最高です;) – Koobz