Su models.py puede estar (y a veces está) vacío. No está obligado a tener un modelo que se asigna a una base de datos.
Aún debe tener un archivo models.py para que el administrador de Django esté contento. El nombre de archivo models.py es importante, y es más fácil tener un archivo vacío que tratar de cambiar el archivo esperado por varios comandos de administración.
El "modelo" - en general - no tiene que asignarse a una base de datos. El "modelo" - como un componente general del diseño de MVC - puede ser cualquier cosa.
Puede, y lo hace a menudo, definir su propio módulo "modelo" que utilizan sus vistas. Simplemente no lo llame models.py porque confundirá a Django admin. Llámalo algo significativo para tu aplicación: foo.py. Este foo.py manipula las cosas reales que sustentan su aplicación, no necesariamente una subclase Django Model.model.
Django MVC no requiere una asignación de base de datos. Espera explícitamente que el módulo llamado models.py tenga una asignación de base de datos en él. Por lo tanto, utilice un models.py vacío si no tiene una asignación de base de datos real.
Su views.py puede utilizar
import foo
def index(request):
objects = foo.somelistofobjects()
*etc.*
Django le permite trabajar fácilmente sin la cartografía de base de datos. Tu modelo puede ser fácilmente cualquier cosa. Simplemente no lo llame models.py.
Editar.
¿Las vistas están registradas con los modelos? No.
¿En la actualización del Modelo por parte del Controlador las Vistas se notifican? No.
¿El Modelo es estrictamente la representación de datos ya que este es realmente MVP? Sí.
Lea los documentos de Django. Es sencillo.
Solicitud web -> Asignación de URL -> Ver función -> Plantilla -> Respuesta.
El modelo puede ser utilizado por la función de vista. El modelo puede ser un mapeo de base de datos, o puede ser cualquier otra cosa.
Tu respuesta puede o no ser correcta, no he usado Django, y han pasado 2 años desde que utilicé Python. Pero esto es lo que odio de lo que los frameworks web han hecho con el concepto de MVC.No existe un requisito rígido de que los datos del modelo en el paradigma MVC provengan de la base de datos. –
El modelo no * tiene que venir de una base de datos. Lo hacemos en nuestras aplicaciones Django. Algunas de nuestras aplicaciones tienen modelos que no están en la base de datos. –
Lo suficiente, pero aparentemente tiene que trabajar de una manera que no es estándar en Django para poder hacerlo. Y, por supuesto, también he visto esto con otros marcos. Creo que todos han hecho un des-servicio a los desarrolladores web impresionables y menos experimentados al introducir la noción de "clases modelo". La mayoría de las veces estas son realmente clases de * entidad *. Ni siquiera estoy de acuerdo en que debería haber algo como una clase de modelo, el modelo está en un nivel de abstracción aún mayor. Una fachada modelo tal vez, pero las clases modelo, no. De todos modos, es mi problema favorito y creo que soy un purista MVC o algo así. –