Conceptualmente estoy tratando de entender si debería estar haciendo esto:
item = Model()
screen = View()
brain = Controller(item, screen)
o esto ..
brain = Controller()
item = Model(brain)
screen = View(brain)
o esto ..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
o algo completamente distinto?
Para mí, la primera opción tiene sentido. El trabajo del controlador es coordinar entre la vista y el modelo. Desde ese punto de vista, tiene sentido que el controlador sea el que controla las referencias a la vista y al modelo.
Realmente no puede tener un controlador sin un modelo y una vista, sin embargo, tiene mucho más sentido tener solo una vista o simplemente tener un modelo (por ejemplo, en pruebas unitarias). Es por eso que desea transferir esas dependencias al controlador, y no a las otras dos.
Los Model y View son independientes entre sí.
No pienses en Controller como brains de la estructura MVC. Piense en ello como el dispatcher que maneja las solicitudes desde el navegador, y dispatches al Model . Luego toma los datos del Model y los empaqueta de forma amigable con plantilla , y luego los envía a un View .
El Model es el cerebro en la estructura MVC, y aquí es donde debe colocar sus reglas comerciales. Las reglas comerciales son comunes en varios controladores . Por lo tanto, un controlador de documento y un controlador de informes pueden usar un modelo de Usuario para ver quién tiene acceso a esas cosas. No querría repetir esas reglas en ambos controladores.
El View debería usar una plantilla HTML para presentar los datos de una manera específica que no sea de origen de datos. No debe estar estrechamente vinculado al esquema de su base de datos. Para mostrar el título de un documento, la vista debería mostrar el contenido de una variable de plantilla llamada document_title , y solo el Controller sabe cómo se estableció esa variable, y solo el Model sabe por qué ese documento tiene ese título .
MVC se definió originalmente para facilitar la programación de aplicaciones de escritorio. La vista se suscribió a eventos del modelo, actualizando la presentación cuando el modelo cambió. El controlador simplemente tradujo los eventos de la interfaz de usuario (por ejemplo, un botón pulsando) en llamadas al modelo. Así que el controlador y la vista dependían del modelo, pero eran independientes entre sí. El modelo era independiente de ambos. Esto permitió que múltiples vistas y controladores funcionaran en el mismo modelo.
La arquitectura "MVC" utilizada para las aplicaciones web 1.0 (actualización de página completa, sin AJAX) es algo diferente. Se envía una solicitud web a un controlador. El controlador de alguna manera modifica el estado del modelo, luego envía uno o más modelos para que sean renderizados por una vista. El controlador y la vista dependen del modelo, pero el controlador también depende de la vista.
Con las aplicaciones web 2.0, volvemos a la arquitectura clásica de MVC, en el lado del cliente . El modelo, la vista y el controlador residen en el lado del cliente como objetos de Javascript. El controlador traduce los eventos del usuario para modelar acciones. Las acciones del modelo pueden o no resultar en una solicitud AJAX al servidor. Nuevamente, la vista se suscribe a eventos modelo y actualiza la presentación en consecuencia.
La vista debe suscribirse a los cambios en el modelo. Hay una latitud en la riqueza de las suscripciones, ya que pueden ser detalladas (me muestran los cambios de inventario para este artículo en particular) o genéricos (el modelo ha cambiado); la vista puede consultar el modelo en respuesta a una notificación de cambio. La vista presenta el conjunto deseado de elementos del modelo en la pantalla, actualizando la pantalla al manejar las notificaciones de cambios.
El controlador debe introducir cambios en el modelo, como resultado de la orientación del usuario (por ejemplo, los comandos de teclado en el menú de poner, mouse y menú).
El modelo mantiene el modelo y una lista de suscripciones, y debe notificar las vistas de los cambios aplicables a través de sus suscripciones.
También debe haber un mecanismo para crear nuevas vistas y controladores (ya que en MVC debería poder tener dos o más vistas del mismo modelo (podrían ser la misma vista (punto) o una vista diferente (punto) s). Lógicamente, podemos considerar que el controlador necesita realizar o tener acceso a una fábrica de vistas y controladores (par), que puede ser parte del controlador u otro componente.
MVC es más como un patrón de modularidad. Su propósito es que siempre que desee cambiar el diseño de la interfaz de usuario (vista), no tenga que cambiar la lógica de la aplicación (controlador) o los procesos de datos internos (modelo).
Para lograr esto, el patrón es aislar la lógica de implementación de cada componente MVC. Aún así, es perfectamente normal que los componentes se conozcan entre sí interfaces .
Lo que vi con frecuencia es que el controlador crea o llama al modelo y la vista (por lo tanto, conoce su interfaz) y el modelo o la vista pueden notificar al controlador (a su vez, más como una devolución de llamada o un patrón de observador). La parte importante es que el controlador no tiene conocimiento de la estructura del diseño.
Lea otras preguntas en las etiquetas mvc