El problema MVCes que las personas piensan que la vista, el controlador y el modelo deben ser lo más independientes posible entre sí. No lo hacen, una vista y un controlador a menudo están entrelazados, piensan en ello como M(VC).
El controlador es el mecanismo de entrada de la interfaz de usuario, que a menudo está enredado en la vista, particularmente con las GUI. Sin embargo, la vista es salida y el controlador es entrada. Una vista a menudo puede funcionar sin un controlador correspondiente, pero un controlador suele ser mucho menos útil sin una vista. Los controladores fáciles de usar utilizan la vista para interpretar la entrada del usuario de una manera más significativa e intuitiva. Esto es lo que hace que sea difícil separar el concepto del controlador de la vista.
Piense en un robot controlado por radio en un campo de detección en una caja sellada como el modelo.
El modelo tiene que ver con el estado y las transiciones de estado sin concepto de salida (visualización) o lo que desencadena las transiciones de estado. Puedo obtener la posición del robot en el campo y el robot sabe cómo cambiar la posición (dar un paso adelante / atrás / izquierda / derecha. Fácil de visualizar sin una vista o un controlador, pero no hace nada útil
Piense en una vista sin un controlador, por ejemplo, alguien en otra habitación de la red en otra habitación observando la posición del robot mientras (x, y) coordina la transmisión por una consola de desplazamiento. Esta vista solo muestra el estado del modelo, pero este tipo no tiene controlador. Nuevamente, es fácil imaginar esta vista sin un controlador.
Piense en un controlador sin vista, por ejemplo, alguien encerrado en un armario con el controlador de radio sintonizado a la frecuencia del robot. Este controlador está enviando entradas y provoca transiciones de estado sin tener idea de lo que le están haciendo al modelo (en todo caso). Fácil de imaginar, pero no realmente útil sin algún tipo de comentarios de la vista.
La mayoría de las UI fáciles de usar coordinan la vista con el controlador para proporcionar una interfaz de usuario más intuitiva. Por ejemplo, imagine una vista / controlador con una pantalla táctil que muestra la posición actual del robot en 2-D y permite al usuario tocar el punto en la pantalla que se encuentra frente al robot. El controlador necesita detalles sobre la vista, por ejemplo, la posición y la escala de la ventana gráfica, y la posición de píxeles del punto tocado en relación con la posición de píxeles del robot en la pantalla) para interpretar esto correctamente (a diferencia del tipo encerrado en el armario con El controlador de radio).
¿Ya respondí tu pregunta? :-)
El controlador es cualquier cosa que recibe información del usuario que se utiliza para hacer que el modelo pase al estado de transición. Intente mantener la vista y el controlador separados, pero tenga en cuenta que a menudo son interdependientes entre sí, por lo que está bien si el límite entre ellos es borroso, es decir, tener la vista y el controlador como paquetes separados puede no estar tan limpiamente separados como lo haría como, pero eso está bien. Es posible que deba aceptar que el controlador no se separará limpiamente de la vista, ya que la vista es del modelo.
... ¿se debe hacer alguna validación, etc. en el controlador? Si es así, ¿cómo retroalimento los mensajes de error a la Vista? ¿Debería volver a pasar por el Modelo o el Controlador debería enviarlo directamente a la Vista?
Si la validación se realiza en la Vista, ¿qué pongo en el Controlador?
Digo que una vista vinculada y un controlador deberían interactuar libremente sin pasar por el modelo. El controlador toma la entrada del usuario y debe realizar la validación (tal vez utilizando información del modelo y / o la vista), pero si la validación falla, el controlador debe poder actualizar su vista relacionada directamente (por ejemplo, mensaje de error).
La prueba de fuego para esto es preguntarse si una vista independiente (es decir, el tipo en la otra habitación que mira la posición del robot a través de la red) debería ver algo o no como resultado del error de validación de otra persona (por ejemplo, el tipo en el armario trató de decirle al robot que saliera del campo). En general, la respuesta es no: el error de validación impidió la transición de estado. Si no hubo transición de estado (el robot no se movió), no hay necesidad de contar las otras vistas. El tipo en el armario simplemente no recibió ningún comentario de que intentó causar una transición ilegal (sin vista, mala interfaz de usuario), y nadie más necesita saber eso.
Si el tipo con la pantalla táctil intentó enviar el robot fuera del campo, recibió un mensaje agradable y fácil de usar que le pedía que no matara al robot enviándolo fuera del campo de detección, pero nuevamente, nadie más necesita saber esto.
Si otros puntos de vista no necesitan saber acerca de estos errores, entonces usted está diciendo efectivamente que las aportaciones de los usuarios y los errores resultantes son parte del modelo y toda la cosa es un poco más complicado ...