relaciones - modelos django=lógica de negocios+acceso a datos? ¿O la capa de acceso a datos debe separarse del modelo django?
django shell (2)
Después de tres años de desarrollo de Django, aprendí lo siguiente.
El ORM es la capa de acceso. Nada más es necesario
El 50% de la lógica de negocios va en el modelo. Parte de esto se repite o amplifica en las Formas.
El 20% de la lógica de negocios va en Formularios. Toda validación de datos, por ejemplo, está en los formularios. En algunos casos, los formularios limitarán un dominio general (permitido en el modelo) a algún subconjunto específico del problema, el negocio o la industria.
El 20% de la lógica empresarial termina en otros módulos de la aplicación. Estos módulos están por encima de los modelos y formularios, pero debajo de las funciones de vista, servicios web RESTful y aplicaciones de línea de comandos.
El 10% de la lógica de negocios termina en aplicaciones de línea de comandos usando la interfaz de comando de administración. Esto es cargas de archivos, extractos y cambios aleatorios al por mayor.
Es muy importante que las funciones de vista y los servicios web RESTful no hagan casi nada. Usan modelos, formularios y otros módulos tanto como sea posible. Las funciones de vista y los servicios web RESTful están limitados a lidiar con los caprichos de HTTP y los diversos formatos de datos (JSON, HTML, XML, YAML, lo que sea).
Intentar inventar aún otra capa de acceso es un ejercicio de valor cero.
En Django, la arquitectura de software sugerida es poner toda la lógica comercial y el acceso a los datos en los modelos.
Sin embargo, algunos colegas sugirieron que la capa de acceso a los datos debe estar separada de la lógica de negocios (capa de servicios comerciales). Su justificación es que la capa de acceso a datos puede aislar los cambios si se usa una fuente de datos diferente. También dicen que hay una lógica de negocios que puede estar en más de un modelo.
Pero cuando empiezo a codificar usando las capas de acceso a datos y lógica de negocios por separado, la capa de acceso a datos es simple (básicamente el código del modelo que define el esquema db) y no parece agregar mucho valor.
¿Realmente tiene sentido separar el acceso a los datos de los modelos django o django ya proporciona una capa de acceso a datos suficiente con su ORM?
Estoy buscando desarrolladores que hayan implementado un buen número de aplicaciones django y descubran cuál es su opinión. Esto es para una aplicación web de tamaño pequeño a mediano.
La respuesta depende de los requisitos de su aplicación.
Para las aplicaciones que siempre usarán bases de datos relacionales y que pueden combinarse con un ORM específico, no es necesario separar el acceso a los datos y los modelos. Django ORM se basa en el patrón de diseño de registro activo, lo que supone que el acceso a datos y el modelo están juntos. Pro es simplicidad, con es menos flexibilidad.
La separación del acceso y el modelo de datos solo es necesaria cuando el desarrollador desea desacoplar por completo la capa de acceso a los datos y la lógica empresarial. Puedes hacerlo con el patrón de diseño del mapeador de datos. Algunos ORM admiten este patrón de diseño, como SQLAlchemy. Pro es más flexibilidad, con es más complejidad.
Recomiendo el libro "Patrones de arquitectura de aplicaciones empresariales" escrito por Martin Fowler para más detalles.