Dónde poner la lógica de negocio en Django

Question

por ejemplo, Cuenta 1 -> * Usuario -> 1 Autenticación 1 cuenta tiene varios usuarios y cada usuario tendrá 1 autentificación

que provienen de fondo java por lo lo que suelo hacer es

1. definen estas clases como Java Beans (es decir, justo get y set, ninguna lógica adjunta)
2. Crear clase EJB administrador de cuentas, definen método create_account (con toma 1 cuenta, lista de usuarios)
3. preparación de datos en la capa web, a continuación, pasar los datos en AccountManager EJB, por ejemplo: accountManager.createAccount(account, userList)

Pero en Django, los defensores del marco que se pone la lógica de dominio en las clases del modelo (nivel de fila) o clases de gestión asociado (nivel de la mesa), lo que hace que las cosas se pongan un poco incómodas. Sí, está bien que si su lógica solo involucra una tabla, pero en la aplicación real, generalmente cada paso involucrará múltiples tablas diferentes o incluso bases de datos, entonces, ¿qué debería hacer en este caso?

¿Poner la lógica en la vista? No creo que esto sea una buena práctica en absoluto. o incluso sobrescribir el método de guardar en la clase de modelo, pasando datos adicionales utilizando ** kwargs? entonces el backend se romperá.

Espero que esto ilustre mi confusión con respecto a dónde debe colocarse la lógica de negocios en una aplicación django.

Answer 1

Bueno, el ejemplo que ilustró anteriormente con accountManager.createAccount (account, userList) parece algo fácil de hacer al agregar un método createAccount al modelo de cuenta. Si siente la necesidad de llevar la lógica comercial fuera del modelo, siempre podría crear un nuevo módulo que aloje su lógica comercial y luego importar y utilizar sus vistas.

Answer 2

No estoy seguro si ha leído la sección en Managers en Django, parece que resuelve su situación actual. Suponiendo que tiene el siguiente modelo Account definido, User está incorporado.

# accounts/models.py 

class AccountManager(models.Manager): 
    def create_account(self, account, user_list): 
     ... 

class Account(models.Model): 
    objects = AccountManager() 

Siéntase libre de separar su código de administrador en un archivo separado si se vuelve demasiado grande. En sus puntos de vista:

# views.py 

from accounts.models import Account 

Account.objects.create_account(account, user_list) 

La lógica de negocio todavía está en los modelos.

EDITAR

La palabra clave aquí es de anulación, no sobrescribe. Si anula el método de guardado del modelo, debe tener en cuenta que cualquier operación de creación y actualización desde su aplicación web y administrador utilizará esta nueva funcionalidad. Si solo desea que la lógica de negocios suceda una vez en una vista específica, es mejor mantenerla fuera de save.

Supongo que puede poner su lógica de negocio en su propia clase regular. Tendrá que instanciar esa clase cada vez que necesite ejecutar su lógica comercial. Alternativamente, puede poner su lógica comercial como una función estática en esta nueva clase si desea omitir el enfoque OOP.

Answer 3

Lo que estoy haciendo es que la mayoría de mis aplicaciones tienen un archivo service.py con lógica empresarial.Esto se debe a que si necesito una función que trabaja con modelos de múltiples aplicaciones que simplemente no puede hacer esto:

# shop/models.py 
from auth.models import User, Team 

Este código será atrapado en el bucle de referencia circular.

Pero voy a mover muy probablemente de service.py a aplicación con estructura como esta:

service/ 
    auth.py 
    customers.py 
    another_set_of_functions.py 
    ...