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 diferente?
Respuestas:
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 pasar esas dependencias al controlador, y no las otras dos.
Los Modely Viewson independientes entre sí.
No pienses en el Controllercomo el cerebro de la estructura MVC. Piense en ello como el despachador que maneja las solicitudes del navegador y las envía al Model. Luego toma los datos del Modely los empaqueta de una manera amigable con la plantilla , y luego los envía a a View.
El Modeles el cerebro en la estructura MVC, y aquí es donde debe poner las reglas de su negocio. Las reglas de negocios son comunes en múltiples controladores . Por lo tanto, un controlador de documentos y un controlador de informes pueden usar un modelo de Usuario para ver quién tiene acceso a esas cosas. No querrás repetir esas reglas en ambos controladores.
El Viewdebe utilizar una plantilla HTML para presentar los datos de una manera específica no fuente de datos. No debe estar estrechamente vinculado al esquema de su base de datos. Para mostrar el título de un documento, debería hacer que la vista muestre el contenido de una variable de plantilla llamada document_title, y solo Controllersabe cómo se configuró esa variable, y solo Modelsabe 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 los eventos del modelo, actualizando la presentación cuando el modelo cambió. El controlador simplemente tradujo los eventos de la interfaz de usuario (por ejemplo, presionar un botón) en llamadas al modelo. Por lo tanto, 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 representados 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, estamos volviendo 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 Javascript. El controlador traduce los eventos del usuario a acciones modelo. 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. Existe latitud en la riqueza de las suscripciones, ya que pueden ser detalladas (muéstrame los cambios de inventario para este artículo en particular) o genéricas (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 como cuando se manejan las notificaciones de cambio.
El controlador debe enviar cambios al modelo, como resultado de la dirección del usuario (p. Ej., Comandos de teclado, 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 existir 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 vista (punto) diferente). Lógicamente, podemos considerar que el controlador necesita realizar o tener acceso a una fábrica de vista y controlador (par), que puede ser parte del controlador u otro componente.
Modelsno notificar Views. Controllersconsulte los Modelcambios y luego renderice Viewspara presentar esos cambios.
MVC es más como un patrón de modularidad. Su propósito es que cada vez 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 procesamientos 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 sus componentes conozcan las interfaces de los demás .
Lo que a menudo vi 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 cambio (más como una devolución de llamada o un patrón de observación). La parte importante es que el controlador no conoce la estructura del diseño.