我有以下情况。
我有一个名为“<strong>Contacts”的现有应用程序,它的型号有number和name。
我想创建一个名为 '<strong>unsubscribe' 的新应用程序,并且我想让它可重用。
这是我的问题:
在名为 unsubscribe 的新应用程序中,它的模型需要一个与联系号码相关的外键。现在这意味着它现在与“联系人”相关联,我不能将它用于我的电子邮件应用程序。从可重用的角度来看,Django 如何处理这个问题?
您可以利用通用关系并创建从取消订阅模型到联系人模型的通用外键关系。这允许您抽象取消订阅和其他对象之间的关系,将它们连接到项目中模型的任何实例。
一个普通的 ForeignKey 只能“指向”另一个模型,这意味着如果 TaggedItem 模型使用一个 ForeignKey,它必须选择一个且只有一个模型来存储标签。contenttypes 应用程序提供了一个特殊的字段类型(GenericForeignKey),它可以解决这个问题并允许关系与任何模型
from django.db import models
from django.contrib.contenttypes.models import ContentType
from django.contrib.contenttypes import generic
class Unsubscription(models.Model):
name = ...
# These two fields allow you to manage the model & instance of object that
# this unsubscribe model instance is related to
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
# This gives you an easy way to get access to the actual instance of the
# instance above
content_object = generic.GenericForeignKey('content_type', 'object_id')
# On the reverse end of the relationship you can add a Generic relation to
# easily get access to all unsubscriptions related to this contact via the GFK
from myapp.models import Unsubscription
class Contact(models.Model):
name = ...
unsubscribtions = generic.GenericRelation(Unsubscribtion)
通常可以在应用程序之间导入模型。这只是创建了一个依赖项,许多应用程序都有。当然,让您的应用程序可独立插入会更加灵活,但重要的是您要记录任何其他尝试使用您的应用程序的人的依赖关系。
如果您真的希望您的应用程序是可插拔的,请考虑重新组织您的应用程序。简单是好的,但过分强调严格、字面上遵守原则可能会妨碍功能。
(没有您的应用程序的具体细节,这只是推测,但由于您描述的所有应用程序都围绕联系人,似乎它们可以简单地重新打包到同一个应用程序中,取消订阅作为联系人中的布尔字段和设置属性的视图. 并且取决于你到底想用电子邮件做什么,类似的东西)