¿Debería el controlador saber acerca de Ver y Modelo? ¿o viceversa?

13

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?

alnafie
fuente

Respuestas:

18

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.

Oleksi
fuente
9

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.

Reactgular
fuente
1
Me gusta su respuesta, ya que se gela con mi comprensión general de MVC. Sin embargo, no aborda una parte importante de la pregunta, ¿específicamente qué partes de la Tríada tienen referencias a las otras? La confusión que creo proviene del hecho de que lo que usted describe es que las Vistas son "plantillas tontas con agujeros" (es decir, no tienen referencia al Controlador, pero el Controlador conoce las Vistas y conecta los datos del Modelo en ellas). Al mismo tiempo, otra cosa común que sigo viendo es que las vistas deben enviar acciones del usuario al controlador. ¿Cómo podrían las vistas hacer esto sin tener una referencia a C?
alnafie
@alnafie Ha simplificado en exceso el marco MVC en solo 3 clases. Eche un vistazo a los marcos de código abierto MVC existentes, y encontrará que se necesita mucho más para que funcione. Tiene que haber algo más alto que gestione todas las piezas para el marco. Algo que llama a los Controladores, y algo que maneja el enrutamiento a las acciones en las Vistas.
Reactgular
3

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.

Kevin Cline
fuente
+1 buena respuesta. Puedo entender devoluciones de llamada modelo para aplicaciones de escritorio en el sentido clásico. Me recuerda al viejo MFC de Microsoft.
Reactgular
2

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.

Erik Eidt
fuente
-1 Modelsno notificar Views. Controllersconsulte los Modelcambios y luego renderice Viewspara presentar esos cambios.
Reactgular
44
@MathewFoscarini en MVC, la Vista se suscribe a los cambios del Modelo. Ver, por ejemplo, wiki.squeak.org/squeak/598 .
Creo que no estamos hablando de diferencias en los marcos MVC existentes. Zend MVC, C # .NET y CakePHP no conectan un modelo a la vista. Una vista en esos marcos es independiente. No sé con qué MVC has trabajado, pero lo llamaría no tradicional.
Reactgular
66
@MathewFoscarini: esos son todos los marcos web, y aunque se autodenominan "MVC", no siguen la arquitectura clásica de MVC.
Kevin Cline
2
No estoy seguro de que ningún MVC sea más "tradicional" que Smalltalk MVC, siendo el primero donde se describió el patrón.
1

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.

Marc-Emmanuel Coupvent des Gra
fuente