Django 常用注释 model 在不同的应用程序中使用

Question

I am creating a project that requires comments in multiple apps like blog , wikis , and pages . I have a commons app that contains all common models. How do I have a Comment model that's common to all apps?

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()

From what I researched, I have the following options,

1. Three Comment models three apps.
2. One Comment model in commons app with ForeignKey relations to the other apps (which I believe will cause circular import issues) and end up with a comment table with multiple columns like blog_id , wiki_id , and page_id .
3. Use Django's GenericForeignKey relationships.

I don't want to do 3. But out of 1 and 2 I would like to know which is the most efficient way to handle this without repeating codes and adding unnecessary database joins.

Or is there a better way to do this?

Answer 1

It's been a while since you asked this question so I'd love to know what conclusions you came to.

One idea would be to create an abstract model in the commons app and then app-specific sub-classes in each app. However, this violates the portability principle since the app will now be dependant upon the commons app.

And therein lies the problem with the idea of a commons app that would contain all the models shared by other apps. While we might consider this to solve the issue of circular references, they are just the symptom of a larger problem caused by ignoring this principle in the first place. Creating further separation only makes things worse.

In your project, you seem to have identified 3 separate web applications and so I think the answer should be to create app-specific models in each one... even if it seems to violate the DRY principle because it favours portability.

In my opinion (which is always subject to change), no app should be dependent upon anything beyond installed modules and Django itself. This ensures portability and thus reusability of code.

I say this knowing that it may result a monolithic application but I feel that this is preferable to circular references caused by cross dependencies. The only solution to that is to spin off core functionality into modules that could be included in any project. The User module included in Django would be a good example of this. Something like django-simple-history would be another. Neither one relies on your code... your code relies upon them.