Django上的用户角色模式

Question

一个伟大的问候社区

我的问题与Django中的管理用户和模式用户的类型有关，首先我向您道歉，以防我的问题可能过于“新手”或者没有意义，我开始将我与Django用户模式及其在项目中工作的不同可能性联系起来。

我有以下情况。

我正在构建一个应用程序，其中我将有三种不同的用户类型：

• 医疗
• 有耐心的
• 理疗师

我正在使用默认的Django身份验证方案(django.contrib.auth)。

最初，我确实认为在这样的实体方案中，用户表是Django保存创建的用户的auth_user表：

​

​

我在User表中有is_patient、is_medical和is_physiotherapist字段，比如布尔属性。

与特定的细节一样，我理解在Django默认模型中，用户是不可能修改或添加属性或字段的。

这是我不能在User表中添加is_patient、is_medical和is_physiotherapist布尔字段的一个重要而有力的原因。

一个典型的建议是使用Userprofile表扩展用户模型，其中我通过OneToOne关系向用户模型添加字段或属性。基本示例如下：

​

​

这样我就可以让Django的用户在特定的时刻拥有现场照片并上传一张.

利用前面的优点，下面的模式可以适合或者可以作为管理用户角色的替代方案(patient、medical和physiotherapist用户类型)？

​

​

我将在以下几个方面建立关系：

• 用户医疗和用户病人
• 使用者物理治疗师及使用者病人

所以在他们和其他桌子之间。

通过这种方法，这些关系不会受到影响？

不同的用户将保存在用户和UserProfile表之间。在可伸缩性方面，这是一个很好的实践吗？我的桌子可能是崩溃还是我的数据库？

此外，我也看到其他选择，例如：

1. 角色表/模型

我将有一个独立或独立的角色表/模型，这可以与Django用户模型相关(一个用户可以通过示例拥有多个角色)--这种方法在我想在专门领域中存储有关角色的独占信息时是有用的？

1. Django权限和授权

我忽视或不知道让我工作的粒度等级。在一个单一的方式中，我已经看到权限和授权系统允许我使用创建、编辑和删除操作.

在这里，我能看到小组的创造吗？例如，一个医疗组并为他们分配权限并将此权限链接到组成该组的用户？这是另一个好的选择吗？这个选项似乎更单一，尽管我不知道用户是否可以根据具有.我不知道这种想法是否正确

1. AUTH_USER_MODEL 创建自定义用户模型

我对病人，医疗和理疗师用户的需求，需要建立一个定制的用户模型？

Answer 1

在这种情况下，特别是如果您想为病人、医生和物理治疗师存储不同的信息，您可以为每个人创建一个模型，并为每个用户模型创建一个OneToOne字段。

class Medic(models.Model):
    user = models.OneToOneField(User, primary_key=True)
    # other fields

class Physio(models.Model):
    user = models.OneToOneField(User, primary_key=True)
    # other fields

class Patient(models.Model):
    user = models.OneToOneField(User, primary_key=True)
    # other fields

通过这种方式，您可以在应用程序逻辑中为每种类型的用户隐式地授予不同的权限/角色(如果特殊情况需要，仍然使用Django提供的组和权限，例如ChiefMedical.)。

您必须为应用程序逻辑定义一些方法，如

def user_is_patient(user):
     ...

如果你沿着这条路走下去，最好是进行好的测试，以确保你不会得到意想不到的东西，比如医生和理疗师.

Django还允许您将用户模型子类化。在封面下，它将执行与上面的代码相同的操作，所以最好像上面所示的那样显式地执行它(这样，您访问不存在于该对象中的属性的可能性就更小了！)

利用前面的优点，下面的模式可以适合或者可以作为管理用户角色的替代方案(患者、医疗和物理治疗师用户类型)。

您显示的架构不是很好，因为它使您将所有用户类型的信息存储在同一个表中(并且具有相同的字段)。例如，医生和理疗师会像病人一样，有一种血型类型，这可能是没有定义的。

不同的用户将保存在用户和UserProfile表之间。在可伸缩性方面，这是一个很好的实践吗？我的桌子可能是崩溃还是我的数据库？

该解决方案不存在可伸缩性问题(只要您没有每天写入数百万个新条目)，而且您可以在以后的某个时候对数据库进行优化。但是，您必须确保您的应用程序不接受“禁止”输入(例如，用户没有医生、理疗师或病人的个人资料)

在这里，我能看到小组的创造吗？例如，一个医疗组并为他们分配权限并将此权限链接到组成该组的用户？这是另一个好的选择吗？这个选项似乎更单一，尽管我不知道用户是否可以根据具有.我不知道这种想法是否正确

您可以(应该)使用Django的权限系统向用户授予权限。您可以使用它们向同一类型的用户授予不同的权限(例如，比其他人拥有更多权限的医疗人员)。或有小组为首席理疗师..)

Django允许为组分配权限。

但是我不认为组可以为每个用户替换自定义模型，因为您希望为它们存储信息。拥有自定义模型和组将是多余的，并使您的应用程序更难维护。

我对病人，医疗和理疗师用户的需求，需要建立一个定制的用户模型？

这个选项不会很好(除非它是您唯一的选择)，因为您的应用程序不会被重用，您可能也会遇到一些软件包的问题。

Answer 2

您可以创建一个自定义用户模型，在任何情况下，您都可以有三个单独的模型来存储相关数据，这取决于用户是病人、医疗、物理治疗师，还是这些数据的任何组合。

如果您的权限方案完全由角色(病人、医疗、物理治疗师)决定，那么您不需要使用Django的权限系统，因为您知道任何用户的角色，在最坏的情况下，您可以使用硬代码授权规则。

Answer 3

我浏览了一下问题的评论，并对一些问题发表了看法：

(

)

我意识到您的用户模型与原始数据模型不匹配，因为在用户模型中包含了get_medical_profile、get_patient_profile和get_physiotherapist_profile函数，并且您假设任何用户都可以同时拥有多个配置文件，这既没有反映在使用OneToOneField的配置文件模型(医疗、病人和物理治疗师)中，也没有反映在问题的原始数据模型中，这对于抽象和类-责任是很重要的。需求(根据下面的模型)似乎是说“一个用户只能拥有一个配置文件”。

​

​

所以..。我认为这可以以一种简单明了的方式解决，您不需要涉及到诸如组和权限之类的整体身份验证，也不需要向用户模型添加其他属性：

class UserProfile(models.Model):
    user = models.OneToOneField(User)
    # common fields shared by medical, patient and physiotherapist profiles

class MedicalUser(models.Model):
    profile = models.OneToOneField(UserProfile)
    # medical fields here

class PatientUser(models.Model):
    profile = models.OneToOneField(UserProfile)
    # patient fields here

class PhysiotherapistUser(models.Model):
    profile = models.ForeignKey(UserProfile)
    # patient fields here

正如您所看到的，您可以拥有一个包含所有配置文件共享的公共字段的配置文件。每个侧写都有一个特定的模型。

此外，您还可以通过下面这个小函数检查用户是否是医疗人员，如果没有与配置文件相关联的医疗配置文件，则会引发异常，这意味着它是未指定的配置文件：

def is_medical_profile(profile):
    try:
        profile.medical_user
        return True
    except:
        return False

您还可以这样在模板中使用它(作为自定义模板标记)：

{% if profile | is_medical_profile %}

使用这种方法，您不需要设置AUTH_USER_MODEL

我希望这能改善你的解决方案。

补充说明：

如果您决定使用自定义用户模型，请设置settings.AUTH_USER_MODEL并将其用于用户的外键。

在一本很棒的书中，两勺Django说：

从Django 1.5开始，官方首选的方式是将ForeignKey、OneToOneField或ManyToManyField附加到用户

因此，您的用户配置文件模型将更改如下：

from django.conf import settings
from django.db import models

class UserProfile(models.Model):
    user = models.OneToOneField(settings.AUTH_USER_MODEL)

是的，看起来有点奇怪，但这正是Django博士的建议。