Separación de lógica de negocios y acceso a datos en django.

| | | | | | | | | | | | | | | | | |

Estoy escribiendo un proyecto en Django y veo que el 80% del código está en el archivo models.py. Este código es confuso y, después de cierto tiempo, dejo de entender lo que realmente está pasando.

Esto es lo que me molesta:

  1. Me parece feo que mi modelo (que se suponía que era responsable solo del trabajo con datos de una base de datos) también envía correos electrónicos, camina sobre la API a otros servicios, etc.
  2. Además, me parece inaceptable colocar la lógica comercial en la vista, porque así se vuelve difícil de controlar. Por ejemplo, en mi aplicación hay al menos tres formas de crear nuevas instancias de Usuario, pero técnicamente debería crearlas de manera uniforme.
  3. No siempre me doy cuenta cuando los métodos y las propiedades de mis modelos se vuelven no deterministas y cuando desarrollan efectos secundarios.

Aquí hay un ejemplo simple. Al principio, el modelo User era así:

class User(db.Models): def get_present_name(self): return self.name or "Anonymous" def activar(self): self.status = "activado" self.save() 

Con el tiempo, se convirtió en esto:

class User(db .Models): def get_present_name(self): # propiedad se volvió no determinista en términos de base de datos # los datos son tomados de otro servicio por api return remote_api.request_user_name(self.uid) o "Anónimo" def active(self): # método ahora tiene un efecto secundario (enviar mensaje al usuario) self.status = "activado" self.save() send_mail("¡Tu cuenta está activada!", "‚Ķ", [self.email]) 

Lo que quiero es separar entidades en mi código:

  1. Entidades de mi base de datos, nivel de persistencia: ¿Qué datos guarda mi aplicación?
  2. Entidades de mi aplicación, nivel de lógica de negocios: ¿Qué hace mi aplicación?

¿Cuáles son las buenas prácticas para implementar tal ¿Qué enfoque se puede aplicar en Django?