Идеи дизайна для веб-приложения в Джанго - PullRequest
2 голосов
/ 20 января 2011

Я работаю над пользовательским веб-приложением типа социальной сети в Django. Это мой первый, поэтому я хотел бы убедиться, что я использую некоторые хорошие практики.

В настоящее время веб-приложение поддерживает два типа пользователей. Это представлено двумя разными группами. Когда я регистрирую пользователя, я назначаю его одной из этих двух групп. У меня также есть два приложения, по одному для каждого типа пользователей. Приложения обрабатывают любые вещи, характерные для определенного типа пользователей. У меня есть другое приложение, которое обрабатывает фактическую аутентификацию. Это приложение использует встроенный тип пользователя Django и назначает им UserProfile. Два разных типа пользователей имеют свои собственные профили, которые расширяются / наследуются от UserProfile.

Это работает достаточно хорошо и достаточно многократно, так как приложение аутентификации может извлечь тип пользователя из URL и выяснить, какой тип пользователя создать. Поскольку группы названы удобно, их также можно добавить в правильную группу.

  1. Это лучший способ или есть более предпочтительные, проверенные и верные способы справиться с этим? Это кажется довольно распространенным сценарием. Я не хочу продолжать неправильно изобретать велосипед, если мне не нужно.
  2. Я думал о добавлении другого приложения, называемого общим или что-то, что будет обрабатывать вещи, которые являются общими для всех пользователей. Например, просмотр страницы профиля пользователя может быть полезен любому, кто вошел в систему, независимо от типа пользователя.

Спасибо!

1 Ответ

2 голосов
/ 20 января 2011

Легкая часть во-первых, с 2) вы на месте. Это был бы самый простой и эффективный способ сделать это. Вместо репликации функций в обоих приложениях имеет смысл иметь одно приложение, которое обрабатывает вещи, общие для обоих типов пользователей.

Вернуться к 1)

С обоими профилями, выходящими из UserProfile, вы столкнетесь с проблемой (если бы вы использовали get_profile () для объекта User - смотрите http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users), что вы получите только объект UserProfile, а не зная, к какой группе пользователь фактически принадлежит, основываясь на полученном объекте, потому что они оба расширяют UserProfile, но UserProfile не сможет (я считаю) абстрагироваться, потому что вы хотите, чтобы каждый пользователь имел указатель на объект UserProfile, который может фактически является объектом UserGroup1 или UserGroup2.

Я бы предложил вам создать две отдельные модели, которые не выходят из одной и той же модели (по необходимости): Group1 и Group2. Вы будете хранить информацию, общую для обоих профилей, в профиле пользователя объекта User. Тогда в UserProfile у вас будет ForeignKey для объекта Group1 и Group2:

group1 = models.ForeignKey(Group1, blank=True, null=True)

Вы должны будете выполнить логику, проверяя себя, чтобы гарантировать, что только один когда-либо действителен (вы могли бы просто сделать это в переопределенном методе save () или чем-то еще), но затем собрать все данные пользователя сразу, а также знать, в какую группу они входят, вы могли бы сделать следующее:

User.objects.filter(username='blahblah').select_related('profile', 'profile__group1', 'profile__group2')

Только один запрос к базе данных даст вам всю необходимую вам информацию о пользователе, и вы также будете знать, в какую группу они входят (та, которая не «Нет»).

Надеюсь, это поможет.

P.S. В этом я предполагаю, что группы имеют не только уникальные данные друг для друга, но и уникальную функциональность.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...