clases desacoplamiento de dominio de las clases Django Modelo

Question

Así que han completado mi análisis y diseño orientado a objetos de una aplicación web que estoy construyendo y recibo actualmente en ejecución. Se han tomado decisiones de diseño para implementar el sistema utilizando Python y el marco de desarrollo web Django.

Quiero empezar a aplicar algunas de mis clases de entidad de dominio que requieren persistencia. Parece que Django quiere que los implemente como clases heredadas de la clase de modelos de Django para usar el ORM de Django para la persistencia. Sin embargo, esto parece un acoplamiento demasiado fuerte entre mis entidades de clase y el mecanismo de persistencia. ¿Qué sucede si en algún momento quiero deshacerme de Django y utilizar otro marco de desarrollo web, o simplemente abandonar el ORM de Django para obtener una alternativa? Ahora tengo que volver a escribir las clases de mi entidad de dominio desde cero.

Así que sería mejor implementar mis clases de dominio como clases Python independientes, encapsulando toda mi lógica comercial en éstas, y luego usar algún mecanismo (patrón de diseño como bridge o adaptador o ???) para delegar el almacenamiento de persistencia de estas clases de dominio para el ORM de Django, por ejemplo a través de una clase de modelo de Django que se ha configurado adecuadamente para esto.

¿Alguien tiene alguna sugerencia sobre cómo hacer esto? De todo lo que he leído parece que las personas simplemente implementan sus clases de dominio como clases heredadas de la clase de modelo de Django y tienen una lógica de negocios mezclada dentro de esta clase. Esto no parece una buena idea para los cambios de línea hacia abajo, mantenimiento, etc. reutilización

Answer 1

Bueno, el camino a seguir con Django es heredar de clases del modelo de base de Django. Este es el patrón de "registro activo". Sus modelos django tendrán todos los métodos CRUD y de consulta junto con su lógica comercial (si decide agregarlo por supuesto). Esto se ve como un antipatrón en el mundo de Java, pero lo bueno de esto es que puede acelerar el desarrollo realmente muy rápido.

Answer 2

¿Puedes en serio imaginar una posibilidad de que vayas a dejar el Django ORM, pero tener todo lo demás? ¿O que si abandonaste totalmente Django, cualquier código seguirá siendo aplicable?

No se quejan de que si abandonaste Django, tendrá que volver a escribir todas sus plantillas. Por supuesto que sí, eso es de esperar. Entonces, ¿por qué está bien que la capa de presentación se vincule con el marco, pero no con la capa de persistencia?

Este tipo de sobreanálisis inicial debe evitarse. Django es una herramienta RAD, y se adapta mejor al desarrollo rápido e iterativo. Por todo eso, es capaz de construir algunas aplicaciones potentes y de larga vida, como lo testificarán muchas compañías grandes. Pero no es Java, y no es "empresarial", y no se ajusta particularmente bien a los principios OO. En el mundo de Python, eso se ve como una característica, no como un error.

Answer 3

Usted no tiene que "volver a escribir sus modelos desde cero" si queríamos un mecanismo de persistencia diferente. El objetivo de un sistema de persistencia de estilo de registro activo es que impone restricciones mínimas en las clases de modelo y actúa en gran medida de forma transparente.

Si usted está realmente preocupado, abstraer cualquier código que se basa en las consultas en sus propios métodos.

Answer 4

Creo que no hay una solución implementada para desacoplar los modelos de Django y las clases de dominio, al menos no he encontrado ninguno. De hecho, el único ORM con tal desacoplamiento que conozco existe solo en el mundo Smalltalk y se llama GLORP. Le permite persistir su modelo de dominio en una base de datos relacional sin tener que modificar las clases de dominio. Actualmente estoy tratando de implementar ideas similares para desacoplar de Django ORM.Mi motivación es que el fuerte acoplamiento actual entre tablas DB y clases de dominio perjudica gravemente la evolución del software. Volveré a publicar si tengo éxito :)