![](/img/trans.png)
[英]Django - Creating a comment system for different pages, using one Comment model
[英]Django common comment model to use in different apps
我正在創建一個需要多個應用程序(如blog
、 wikis
和pages
)中的評論的項目。 我有一個包含所有常見模型的commons
應用程序。 我如何擁有所有應用程序共有的Comment
model?
公共/模型.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)
博客/models.py
class Post(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='posts')
content = models.TextField()
維基/models.py
class Wiki(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='wikis')
content = models.TextField()
根據我的研究,我有以下選擇,
Comment
模型三個應用程序。commons
應用程序中的一條Comment
model 與其他應用程序的 ForeignKey 關系(我相信這會導致循環導入問題)並最終得到一個包含多個列的評論表,如blog_id
、 wiki_id
和page_id
。GenericForeignKey
關系。我不想做 3。但是在 1 和 2 中,我想知道在不重復代碼和添加不必要的數據庫連接的情況下,哪種方法是處理此問題的最有效方法。
還是有更好的方法來做到這一點?
你問這個問題已經有一段時間了,所以我很想知道你得出了什么結論。
一個想法是在公共應用程序中創建一個抽象 model,然后在每個應用程序中創建特定於應用程序的子類。 但是,這違反了可移植性原則,因為該應用程序現在將依賴於公共應用程序。
這就是commons
應用程序包含其他應用程序共享的所有模型的想法的問題。 雖然我們可能會考慮這樣做來解決循環引用的問題,但它們只是最初忽略這一原則導致的更大問題的症狀。 進一步分離只會讓事情變得更糟。
在您的項目中,您似乎已經確定了 3 個單獨的 web 應用程序,因此我認為答案應該是在每個應用程序中創建特定於應用程序的模型......即使它似乎違反了 DRY 原則,因為它有利於便攜性。
在我看來(這總是會發生變化),除了已安裝的模塊和 Django 本身之外,任何應用程序都不應該依賴於任何東西。 這確保了可移植性,從而確保了代碼的可重用性。
我這樣說是知道它可能會導致一個單一的應用程序,但我覺得這比由交叉依賴引起的循環引用更可取。 唯一的解決方案是將核心功能分拆成可以包含在任何項目中的模塊。 Django 中包含的用戶模塊就是一個很好的例子。 像 django-simple-history 這樣的東西將是另一個。 沒有人依賴你的代碼......你的代碼依賴於他們。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.