2010-12-30 37 views
5

Supongamos que tiene una aplicación donde diferentes tipos de usuarios pueden firmar: Firmas, abogados y clientes. Una firma tiene muchos abogados; un abogado tiene muchos clientes. Las opiniones para un usuario firme son, por supuesto, diferentes de las opiniones de un usuario de abogado; los dos son diferentes del usuario del cliente.Cuentas de modelado para diferentes tipos de usuarios en Django

¿Cómo modelizarías a los tres usuarios diferentes? No puedo pensar en el siguiente enfoque:

tres modelos diferentes con una ForeignKey a User, cada uno con sus propios campos, por ejemplo:

class Firm(models.Model): 
user = models.ForeignKey(User) 
class Lawyer(models.Model): 
user = models.ForeignKey(User) 
specialty = models.CharField(max_length=100) 
class Client(models.Model) 
user = modelsForeignKey(User) 

Ahora puede crear, por ejemplo, las consultas como un modelo separado utilizando dos ForeignKeys: a Lawyer y a Client; también puede agregar recursos a una consulta (como documentos, o cosas por el estilo) creando un modelo Resource con un ForeignKey a Consultation.

Este enfoque hace que sea difícil distinguir entre los usuarios: ¿cómo saber si un user es una Firm, por ejemplo - que necesita para consultar las bases de datos varias veces o asignar un Profile a la User objeto genérico.

También puede agregar sólo un Profile a la User e incluyen un Role, y luego se canalizan los puntos de vista y la autenticación basada en user.get_profile().role.

¿Cómo lidiarías con este problema?

Respuesta

5

me gustaría hacer lo que usted sugiere aquí:

También puede agregar sólo un perfil para el usuario y que incluya una función, y luego canalizar las opiniones y la autenticación basada en user.get_profile() función. .

Cree un perfil con un campo de opción para el rol. Cree decoradores como @lawyer_only para asegurarse de que sus puntos de vista solo sean accesibles para los usuarios de roles de Lawyer.

+0

Sí, creo que tendré que ir con esto. ¡Gracias! (Buena idea sobre los decoradores) – Escualo

0

También podría considerar la subclasificación el modelo de usuario (modelo de herencia): http://docs.djangoproject.com/en/dev/topics/db/models/#model-inheritance

Usted tendrá que ir con la opción de herencia de varias mesas http://docs.djangoproject.com/en/dev/topics/db/models/#multi-table-inheritance ya que la clase de usuario no es un modelo abstracto.

+0

Esto es solo una sintaxis de azúcar para las relaciones de OneToOne. No veo un beneficio sobre OneToOne explícito. –

+0

@Mike: No exactamente. Cuando diseño OO-software, prefiero pensar en términos del modelo de objetos como mi principal preocupación (el almacenamiento de datos viene después). Por lo tanto, si un abogado es un usuario, prefiero que esta relación "es una" explícita en mi código, de modo que pueda usar una instancia de abogado siempre que se espere una instancia de usuario. Por cierto, la herencia del modelo ORM y la composición única de la misma manera (como una relación uno-a-uno). Dicho esto, la herencia del modelo de Django tiene algunos caprichos que hacen que no funcione exactamente como herencia de objetos. –

Cuestiones relacionadas