Estructura del modelo MVC en Python

Question

Tengo problemas para estructurar clases en la parte Modelo de un patrón MVC en mi aplicación Python. No importa cómo cambie las cosas, sigo encontrándome con importaciones circulares. Esto es lo que tengo:

Modelo/__init__p.y

• debería contener todos los nombres de clase de modelo Puedo hacer un " desde el usuario de importación de modelos " p.ej. desde un controlador o una unidad caso de prueba

Model / Database.py

• contiene la clase de base de datos
• necesita importar todas las clases de Modelo para hacer ORM
• la inicialización se debe realizar en la importación del primer módulo, es decir, no hay llamadas de inicio adicionales o instancias (todos los métodos en la clase de Base de Datos son @classmethods)

Modelo/Usuario.py

• contiene clase de modelo de usuario
• necesita acceso a la clase de base de datos para hacer consultas
• debe heredar de la clase base común a todas las clases de Modelo para compartir funcionalidad (métodos de persistencia de la base de datos, código de validación de parámetros, etc.)

Todavía no he visto una aplicación de Python del mundo real que emplee MVC, por lo que mi enfoque probablemente no sea Pythonic (y posiblemente un desastre agnóstico de lenguaje además de eso ...) - ¿Alguna sugerencia sobre cómo resolver esto?

Gracias, Simon

Answer 1

Hay una inconsistencia en su especificación. Dices que Database.py necesita importar todas las clases de Modelo para hacer ORM, pero luego dices que la clase de Usuario necesita acceso a la Base de Datos para hacer consultas.

Piense en esto como capas de una API. La clase de base de datos proporciona una API (quizás orientada a objetos) a alguna capa de persistencia física (como DB-API 2.0). Las clases Modelo, como Usuario, usan la capa Base de datos para cargar y guardar su estado. No hay ninguna razón para que la clase Database.py importe todas las clases Model, y de hecho no querría eso porque tendría que modificar Database.py cada vez que creara una nueva clase Model, que es un olor a código .

Answer 2

Generalmente, lo ponemos todo en un archivo. Esto no es Java o C ++.

Comience con un solo archivo hasta que obtenga más experiencia con Python. A menos que sus archivos sean gigantescos, funcionará bien.

Por ejemplo, Django fomenta este estilo, así que copie su fórmula para el éxito. Un módulo para el modelo. Un módulo para cada aplicación; cada aplicación importa un modelo común.

Su base de datos y material de superclase pueden estar en su archivo __init__.py , ya que se aplica a todo el paquete. Eso puede reducir algo de la circularidad.

Answer 3

Creo que tienes un problema que debería resolverse. Las referencias circulares a menudo resultan de una falla en lograr la separación de las preocupaciones. En mi opinión, la base de datos y los módulos modelo no deberían saber mucho el uno del otro, sino que funcionan contra una API. En este caso, la base de datos no debería hacer referencia directa a ninguna clase de modelo específica, sino proporcionar la funcionalidad que las clases de modelo necesitarán para funcionar. El modelo, a su vez, debería obtener una referencia de base de datos (inyectada o solicitada) que usaría para consultar y persistir.