在不同应用程序中使用的 Django 通用评论模型
Django common comment model to use in different apps
我正在创建一个需要在 blog
、wikis
和 pages
等多个应用程序中发表评论的项目。我有一个包含所有常见模型的 commons
应用程序。我如何拥有所有应用程序通用的 Comment
模型?
commons/models.py
class Comment(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='comments')
body = models.TextField()
parent = models.ForeignKey('self', on_delete=models.CASCADE, null=True)
blog/models.py
class Post(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='posts')
content = models.TextField()
wikis/models.py
class Wiki(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='wikis')
content = models.TextField()
根据我的研究,我有以下选择,
- 三个
Comment
模型三个应用程序。
-
commons
应用程序中的一个 Comment
模型与其他应用程序具有外键关系(我认为这会导致循环导入问题)并以包含多列的评论 table 结尾像 blog_id
、wiki_id
和 page_id
。
- 使用 Django 的
GenericForeignKey
关系。
我不想做 3。但是在 1 和 2 中,我想知道哪种是最有效的处理方式,无需重复代码和添加不必要的数据库连接。
或者有更好的方法吗?
你问这个问题已经有一段时间了,所以我很想知道你得出了什么结论。
一个想法是在公共应用程序中创建一个抽象模型,然后在每个应用程序中创建特定于应用程序的子类。但是,这违反了可移植性原则,因为应用程序现在将依赖于公共应用程序。
commons
应用程序的想法存在问题,该应用程序将包含其他应用程序共享的所有模型。虽然我们可能认为这是为了解决循环引用的问题,但它们只是由于首先忽略该原则而导致的更大问题的症状。制造进一步的分离只会让事情变得更糟。
在你的项目中,你似乎已经确定了 3 个独立的 Web 应用程序,所以我认为答案应该是在每个应用程序中创建特定于应用程序的模型......即使它似乎违反了 DRY 原则,因为它有利于便携性。
在我看来(总是会发生变化),任何应用程序都不应依赖于已安装的模块和 Django 本身之外的任何东西。这确保了代码的可移植性和可重用性。
我这么说是因为我知道它可能会导致一个单体应用程序,但我觉得这比由交叉依赖引起的循环引用更可取。唯一的解决方案是将核心功能分拆成可以包含在任何项目中的模块。 Django 中包含的用户模块就是一个很好的例子。像 django-simple-history 这样的东西是另一个。两者都不依赖于您的代码...您的代码依赖于它们。
我正在创建一个需要在 blog
、wikis
和 pages
等多个应用程序中发表评论的项目。我有一个包含所有常见模型的 commons
应用程序。我如何拥有所有应用程序通用的 Comment
模型?
commons/models.py
class Comment(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='comments')
body = models.TextField()
parent = models.ForeignKey('self', on_delete=models.CASCADE, null=True)
blog/models.py
class Post(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='posts')
content = models.TextField()
wikis/models.py
class Wiki(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='wikis')
content = models.TextField()
根据我的研究,我有以下选择,
- 三个
Comment
模型三个应用程序。 -
commons
应用程序中的一个Comment
模型与其他应用程序具有外键关系(我认为这会导致循环导入问题)并以包含多列的评论 table 结尾像blog_id
、wiki_id
和page_id
。 - 使用 Django 的
GenericForeignKey
关系。
我不想做 3。但是在 1 和 2 中,我想知道哪种是最有效的处理方式,无需重复代码和添加不必要的数据库连接。
或者有更好的方法吗?
你问这个问题已经有一段时间了,所以我很想知道你得出了什么结论。
一个想法是在公共应用程序中创建一个抽象模型,然后在每个应用程序中创建特定于应用程序的子类。但是,这违反了可移植性原则,因为应用程序现在将依赖于公共应用程序。
commons
应用程序的想法存在问题,该应用程序将包含其他应用程序共享的所有模型。虽然我们可能认为这是为了解决循环引用的问题,但它们只是由于首先忽略该原则而导致的更大问题的症状。制造进一步的分离只会让事情变得更糟。
在你的项目中,你似乎已经确定了 3 个独立的 Web 应用程序,所以我认为答案应该是在每个应用程序中创建特定于应用程序的模型......即使它似乎违反了 DRY 原则,因为它有利于便携性。
在我看来(总是会发生变化),任何应用程序都不应依赖于已安装的模块和 Django 本身之外的任何东西。这确保了代码的可移植性和可重用性。
我这么说是因为我知道它可能会导致一个单体应用程序,但我觉得这比由交叉依赖引起的循环引用更可取。唯一的解决方案是将核心功能分拆成可以包含在任何项目中的模块。 Django 中包含的用户模块就是一个很好的例子。像 django-simple-history 这样的东西是另一个。两者都不依赖于您的代码...您的代码依赖于它们。