usa - Dónde poner la lógica de negocios en django.

que base de datos usa django

Question

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

Vengo de Java, así que lo que suelo hacer es

1. define estas clases como beans java (es decir, solo getter y setter, sin lógica adjunta)
2. crear la clase ejb de AccountManager, definir el método create_account (con toma 1 cuenta, lista de usuarios)
3. preparar datos en la capa web, luego pasar datos a AccountManager ejb, por ejemplo: accountManager.createAccount(account, userList)

Pero en django, el marco de trabajo recomienda que coloque la lógica de dominio en clases modelo (nivel de fila) o clases de administrador asociadas (nivel de tabla), lo que hace que las cosas sean un poco difíciles. Sí, está bien que si su lógica solo involucra una tabla, pero en la aplicación real, por lo general, cada paso involucrará varias tablas diferentes o incluso bases de datos, entonces, ¿qué debo hacer en este caso?

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

Espero que esto ilustre mi confusión con la ubicación de 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 que podría hacerse fácilmente al agregar un método createAccount al modelo de cuenta. Si siente la necesidad de llevar la lógica de negocios fuera del modelo, siempre puede crear un nuevo módulo que contenga la lógica de su negocio y luego importar y usar en sus vistas.

Answer 2

Lo que estoy haciendo es que la mayoría de mis aplicaciones tienen un archivo service.py con lógica de negocios. Esto se debe a que si necesito una función que funcione con modelos de varias aplicaciones, simplemente no puedo hacer esto:

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

Este código se pegará en el bucle de referencia circular.

Pero probablemente me moveré de service.py a una aplicación con una estructura como esta:

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

Answer 3

No estoy seguro de haber leído la sección sobre Managers en Django, parece que resuelve tu situación actual. Suponiendo que tiene definido el siguiente modelo de Account , el User está integrado.

# 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 es 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 sigue en los modelos.

EDITAR

La palabra clave aquí es sobrescribir, no sobrescribir. 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 esa lógica de negocios suceda una vez en una vista específica, puede ser mejor mantenerla fuera de save .

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