En MVC, ¿pueden varias vistas tener el mismo controlador o una vista debe tener un único controlador?

14

Tengo algunas preguntas al diseñar una arquitectura para un proyecto en torno a MVC. (Es un proyecto de C ++ / Marmalade SDK, no estoy usando ningún framework MVC en particular, estoy haciendo uno).

En varios artículos (como en el artículo original de Steve Burbek ) Sigo leyendo el concepto "tríada MVC", que me atasca ya que tomé este concepto de manera bastante literal. Cuando lo leí por primera vez, parecía que una aplicación estaba construida alrededor de unidades de "tríada MVC", una para cada pieza de UI que suponía, pero esto me parece poco flexible y creo que no es así como se pretendía usar MVC. Luego, investigando más a fondo el problema, encontré varios ejemplos de acoplamiento apretado del controlador y la vista, a saber, relación 1 a 1: TextEditView tiene TextEditController.

Pero cuando vuelvo a mi proyecto, encuentro que podría ser útil tener un controlador (por 'unidad lógica', como AddElementController) y varias vistas para ese controlador en particular.

Claramente, estoy pensando en algo como un AddElementController que debería tener algún tipo de interfaz de usuario de pestaña. ¿Debo tener un AddElementController que tenga un AddElementTabView y varios AddImageView, AddSoundView, etc. para las pestañas? ¿O debería tener un 'subcontrolador' diferente para cada vista de pestaña?

En resumen, y en relación con el patrón MVC (no la comprensión / implementación particular de este marco en X), ¿es correcto tener varias vistas para un controlador o cada vista debe tener su controlador particular?

Además, ¿es correcto mantener cierta información de estado en el controlador o debería ser sin estado (lo que significa que el estado debería ubicarse en algún modelo de estado que no sea de dominio)?

Gracias a todos por adelantado.

    
pregunta pedrosanta 20.05.2012 - 06:47

4 respuestas

14

El problema es que el patrón MVC se diseñó en un sistema que ya no existe realmente. Se inventó en Smalltalk en un momento en que las bibliotecas de IU no existían. Para crear un cuadro de diálogo de ventana, dibujó todos los cuadros, resaltó los cuadrados correspondientes, se aseguró de que el texto que estaba dibujando terminara en el lugar correcto ... etc ...

Imagina cómo sería escribir una aplicación de diálogo utilizando solo un gran lienzo. Ese es el mundo del que proviene MVC.

Una "vista" en este sistema era un cuadro de texto y era una clase responsable de dibujar el cuadro, el texto, dibujar áreas seleccionadas, responder a cambios en el texto, etc. ...

Un "controlador" fue otra clase que tomó los eventos del mouse que ocurrieron dentro de este cuadro como el movimiento del mouse, la tecla hacia abajo, la tecla arriba, los clics, etc. y decidiría qué sucedió. ¿Debemos cambiar el texto? ¿Debemos cambiar la selección? Cosas así.

Un "modelo" era otra clase que representaba los datos básicos y el estado del componente. Un modelo de cuadro de texto tendría el texto, por supuesto, la fuente, la selección, etc ...

Como puede ver, en una situación como esta, los tres componentes están muy enredados en la representación de una sola idea. En este contexto, tiene sentido hablar de una "tríada".

Hoy, si está trabajando en la creación de una biblioteca de IU y en el uso de comandos de dibujo sin formato, podría hacer algo similar. Pero la aplicación del patrón "MVC" se ha extendido más allá de su propósito inicial. Hoy en día, tiene una "vista" que puede ser en realidad un cuadro de diálogo completo, y un controlador que responde a eventos como "texto cambiado" o "botón presionado". El modelo en el MVC actual normalmente es algo bastante desconectado del sistema (pero generalmente está vinculado a la vista al proporcionar una interfaz de observador de algún tipo) y puede haber muchas vistas asociadas con el modelo.

En un sistema que he diseñado recientemente, por ejemplo, teníamos alrededor de más de 10 visitas, todos observando un "titular" de un solo documento y su documento activo. Una interfaz de dibujo principal interactuó con el diseño del documento, varias vistas de propiedades que observaron el elemento seleccionado y proporcionaron una interfaz de registro, y una representación a menor escala de la vista principal que mostraba todo el documento en lugar de solo la ventana visible. Algunas de estas vistas tenían controladores de complejidad variable que convirtieron los eventos de la GUI en cambios al documento, lo que a su vez notificaría sus diversas vistas.

¿Aún puedes llamar a esta relación una "tríada"? Quizás, pero creo que implica demasiado de la antigua aplicación MVC anterior.

¿Podrías compartir controladores con diferentes vistas? Depende de cuán similares sean las vistas. Descubrí que, en general, este tipo de objeto tiene un comportamiento específico a la vista que controla Y el modelo que está manipulando para ser muy reutilizable ... pero siempre hay excepciones.

    
respondido por el Crazy Eddie 20.05.2012 - 09:20
5

Depende. Hay varias variantes de MVC, algunas donde solo una relación 1: 1 tiene sentido (como "el humilde cuadro de diálogo"), otras donde este no es el caso. Recomendaría leer el Construya Serie de artículos propios de CAB , que explican las variantes MVC más importantes.

    
respondido por el Doc Brown 20.05.2012 - 08:08
3

Las vistas no tienen Controladores en MVC. El controlador es el jefe, por lo que un controlador decide qué vista se va a representar y a las vistas no les importa o no le importa qué controlador solicitó la vista.

Usted puede / absolutamente tendrá múltiples Vistas desde un Controlador. Solo piense en crear un modelo para cada vista si desea mantener el patrón MVC.

    
respondido por el Mert Akcakaya 20.05.2012 - 07:48
3

El objetivo del controlador es controlar las interacciones del usuario con su modelo de dominio, es decir, es un nivel de direccionamiento indirecto entre lo que ve el usuario (la vista) y el estado de sus aplicaciones (el modelo).

Cuando el usuario realiza una solicitud, se dirige a un controlador. El controlador decide cómo transmitir esa solicitud a la aplicación, generalmente a través de algún tipo de clase de servicio. Luego, interpreta la respuesta de esa clase de servicio y decide qué vista enviar al usuario.

Un controlador siempre puede devolver la misma vista (1: 1) si solo hay un tipo de solicitud que el usuario puede hacer del controlador y siempre requiere el mismo tipo de respuesta. Por ejemplo, HelloWorldController siempre devolverá un HelloWorldView mostrando "¡Hola, mundo!"

Por otro lado, un controlador a menudo tiene que decidir sobre diferentes vistas, dependiendo de lo que el modelo le diga. El TeamRosterController podría devolver un RugbyTeamRosterView o un FootbalTeamRosterView , dependiendo del tipo de equipo solicitado.

En general, es preferible que los controladores sean apátridas, aunque puede ser necesario o deseable algún acceso al estado de la sesión del usuario. Debería administrar el acceso a ese estado por separado si es posible.

Recomiendo encarecidamente ver un marco MVC real para ver qué hace y cómo funciona. No tiene que usarlo, pero definitivamente obtendría un mejor entendimiento antes de crear el suyo propio.

    
respondido por el Matthew Flynn 20.05.2012 - 08:43

Lea otras preguntas en las etiquetas