2010-10-04 3 views
2

ists,Модели Django: подход подкласса?

Я ищу некоторую проверку на подклассическом подходе. У меня есть следующий:

class Person(models.Model): 
    """ 
    Basic person 
    """ 
    user = models.ForeignKey(User) # hide 
    first_name = models.CharField(max_length=200) 
    last_name = models.CharField(blank=True, max_length=200) 

    class Meta: 
     verbose_name_plural = "People" 

    def __unicode__(self): 
     return u"%s, (%s)" % (self.first_name, self.user) 


class Contributor(Person): 
    """ 
    Contributor 
     A Core contributor of the site content workflow 
    """ 

    class Meta: 
     verbose_name = 'contributor' 
     verbose_name_plural = 'contributors' 

    def get_articles(self): 
     """ 
     Return the articles that the author has published. 
     """ 
     return Article.objects.filter(self_in=authors) 

class Member(Person): 
    """ 
    Member 

     A Member of the website. 
    """ 

    # Member history, payments etc... 
    joined = models.DateTimeField() 

Таким образом, каждый член или Вкладчик является лицом в системе, но это возможно для человека, чтобы быть «None», 1 или оба членов & Вкладчика, в зависимости от контекста.

Этот подклассов подход позволяет легко делать такие вещи, как:

#... 
contributors = models.ManyToManyField(Contributor, help_text="Contributors/Authors to this article") 

или

print Member.objects.all() 

... и, конечно, обычные эффективностей подклассов, то есть общих полей и методов.

Однако, мне интересно, о плюсах & против делать что-то вроде

class Person(models.Model): 
    """ 
     Person 
     """ 
     user = models.ForeignKey(User) # hide 
     first_name = models.CharField(max_length=200) 
     last_name = models.CharField(blank=True, max_length=200) 
     is_contributor = models.BooleanField() 
     is_member = models.BooleanField() 

но необходимости фильтровать такие вещи, как

# Assuming this is possible... 
contributors = models.ManyToManyField(Person.objects.filter(is_contributor=True), help_text="Contributors/Authors to this article") 

С подклассов подходе Интересно о проблемах осознавать пользователей, которые являются людьми (людьми), членами или участниками, и быть способными различать между ними.

т.е. его очень легко сделать if person.is_contributor:, но, возможно, более сложных

try: 
    Contributor.objects.get(person__user_id=request.user.id) 
except: 
    no_access() 
else: 
    let_them_in() 

Извинения для открытого endness этого вопроса - это, возможно, было больше, возможность думать вслух.

ответ

2

Во-первых, есть две странности о вашей модели, чтобы начать с:

1) Почему Person - => Пользователь ForeignKey и не OneToOne? Может ли пользователь быть более чем одним человеком?

2) У пользователя уже есть имя и фамилия - почему также назначать их человеку?

Далее, насколько ваша конечная цель - это разрешение, указанное в конце, почему бы просто не использовать разрешения? Тогда вам не понадобятся логические поля или try - кроме как в конце.

По сути, я не вижу ничего плохого в подклассе модели пользователя. Люди в #django часто борются за это, но если все сделано правильно, это один из самых экономичных и эффективных шагов, которые вы можете предпринять, когда впервые сядете с новым проектом django.

Добавление различных подклассов Пользователя с различными атрибутами и различными методами может очень быстро дать вам надежную пользовательскую среду с огромными возможностями auth. До сих пор, однако, похоже, что вы не сделали ничего, что требует от вас подкласса User.

Смежные вопросы