¿Qué es realmente MVC?

Como programador serio, ¿cómo responde a la pregunta ¿Qué es MVC?

En mi opinión, MVC es una especie de tema nebuloso, y debido a eso, si tu audiencia es un aprendiz, entonces eres libre de describirlo en términos generales que es poco probable que sean controvertidos.

Sin embargo, si está hablando con una audiencia bien informada, especialmente un entrevistador, me resulta difícil pensar en una dirección que no tome el riesgo de una reacción de "¡bueno, eso no está bien! ...". Todos tenemos diferentes experiencias en el mundo real, y realmente no he cumplido el mismo patrón de implementación MVC dos veces.

Específicamente, parece haber desacuerdos con respecto a la rigurosidad, la definición de los componentes, la separación de las partes (qué pieza encaja dónde), etc.

Entonces, ¿cómo debo explicar MVC de manera correcta, concisa y sin controversias?

MVC es una arquitectura de software, la estructura del sistema, que separa la lógica de dominio / aplicación / negocio (lo que prefiera) del resto de la interfaz de usuario. Lo hace separando la aplicación en tres partes: el modelo, la vista y el controlador.

El modelo gestiona comportamientos y datos fundamentales de la aplicación. Puede responder a solicitudes de información, responder a instrucciones para cambiar el estado de su información e incluso notificar a los observadores en sistemas controlados por eventos cuando la información cambia. Esto podría ser una base de datos, o cualquier número de estructuras de datos o sistemas de almacenamiento. En resumen, son los datos y la gestión de datos de la aplicación.

La vista proporciona efectivamente el elemento de interfaz de usuario de la aplicación. Representará los datos del modelo en un formulario adecuado para la interfaz de usuario.

El controlador recibe la entrada del usuario y realiza llamadas a los objetos del modelo y la vista para realizar las acciones apropiadas.

Con todo, estos tres componentes trabajan juntos para crear los tres componentes básicos de MVC.

Analogía

Le expliqué MVC a mi papá así:

MVC (Modelo, Vista, Controlador) es un patrón para organizar el código en una aplicación para mejorar la capacidad de mantenimiento.

Imagine un fotógrafo con su cámara en un estudio. Un cliente le pide que tome una foto de una caja.

El cuadro es el modelo , el fotógrafo es el controlador y la cámara es la vista .

Debido a que la caja no sabe acerca de la cámara o el fotógrafo, es completamente independiente. Esta separación le permite al fotógrafo caminar alrededor de la caja y apuntar la cámara en cualquier ángulo para obtener la toma / vista que desea.

Las arquitecturas no MVC tienden a estar estrechamente integradas entre sí. Si la caja, el controlador y la cámara fueran uno y el mismo objeto, tendríamos que separarnos y luego reconstruir tanto la caja como la cámara cada vez que quisiéramos obtener una nueva vista. Además, tomar la foto siempre sería como tratar de tomar una selfie, y eso no siempre es muy fácil.

Explicación detallada

Fue solo después de leer la siguiente pregunta / respuesta maillist que sentí que entendía MVC. Cita: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha escribió:

El autor se refiere a mvctree.py en wxPython como un ejemplo de diseño MVC. Sin embargo, todavía soy demasiado ecológico, así que encuentro ese ejemplo en particular demasiado complejo y no entiendo la separación que el autor recomienda.

MVC tiene que ver con la separación de las preocupaciones.

El Modelo es responsable de administrar los datos del programa (tanto los datos privados como los del cliente). La Vista / Controlador es responsable de proporcionar al mundo exterior los medios para interactuar con los datos del cliente del programa.

El modelo proporciona una interfaz interna (API) para permitir que otras partes del programa interactúen con él. La Vista / Controlador proporciona una interfaz externa (GUI / CLI / formulario web / IPC de alto nivel / etc.) para permitir que todo fuera del programa se comunique con él.

El Modelo es responsable de mantener la integridad de los datos del programa, porque si eso se corrompe, entonces se acaba el juego para todos. La Vista / Controlador es responsable de mantener la integridad de la IU, asegurándose de que todas las vistas de texto muestren valores actualizados, deshabilitando elementos del menú que no se aplican al foco actual, etc.

El modelo no contiene código de vista / controlador; no hay clases de widgets GUI, no hay código para diseñar cuadros de diálogo o recibir la entrada del usuario. La vista / controlador no contiene código de modelo; no hay código para validar URL o realizar consultas SQL, y tampoco hay un estado original: cualquier dato contenido por widgets es solo para fines de visualización, y simplemente es un reflejo de los datos verdaderos almacenados en el Modelo.

Ahora, aquí está la prueba de un verdadero diseño MVC: el programa debería ser esencialmente funcional incluso sin una Vista / Controlador conectado. De acuerdo, el mundo exterior tendrá problemas para interactuar con él de esa forma, pero siempre que uno conozca los encantamientos de la API del modelo apropiado, el programa mantendrá y manipulará los datos de manera normal.

¿Por qué es esto posible? Bueno, la respuesta simple es que todo es gracias al bajo acoplamiento entre las capas Modelo y Vista / Controlador. Sin embargo, esta no es la historia completa. Lo que es clave para todo el patrón MVC es la dirección en la que van esas conexiones: TODAS las instrucciones fluyen desde la Vista / Controlador al Modelo. El modelo NUNCA le dice a la Vista / Controlador qué hacer.

¿Por qué? Porque en MVC, mientras que la Vista / Controlador puede saber un poco sobre el Modelo (específicamente, la API del Modelo), pero el Modelo no puede saber nada sobre la Vista / Controlador.

¿Por qué? Porque MVC se trata de crear una clara separación de preocupaciones.

¿Por qué? Para ayudar a evitar que la complejidad del programa se salga de control y lo entierre a usted, el desarrollador, debajo de él. Cuanto más grande es el programa, mayor es el número de componentes en ese programa. Y cuantas más conexiones existan entre esos componentes, más difícil será para los desarrolladores mantener / ampliar / reemplazar componentes individuales, o incluso simplemente seguir cómo funciona todo el sistema. Pregúntese esto: al mirar un diagrama de la estructura del programa, ¿preferiría ver un árbol o la cuna de un gato? El patrón MVC evita esto último al no permitir conexiones circulares: B puede conectarse a A, pero A no puede conectarse a B. En este caso, A es el Modelo y B es la Vista / Controlador.

Por cierto, si eres agudo, notarás un problema con la restricción 'unidireccional' que acabamos de describir: ¿cómo puede el Modelo informar a la Vista / Controlador de los cambios en los datos de usuario del Modelo cuando ni siquiera se le permite sabe que la Vista / Controlador, no importa enviarle mensajes? Pero no se preocupe: hay una solución para esto, y es bastante ordenada, incluso si al principio parece un poco indirecta. Volveremos a eso en un momento.

En términos prácticos, entonces, un objeto de Vista / Controlador puede, a través de la API del Modelo, 1. decirle al Modelo que haga cosas (ejecutar comandos) y 2. decirle al Modelo que le dé cosas (devolver datos). La capa Vista / Controlador envía instrucciones a la capa Modelo y extrae información de la capa Modelo.

Y ahí es donde su primer ejemplo de MyCoolListControl falla, porque la API para esa clase requiere que la información se inserte en ella, por lo que vuelve a tener un acoplamiento bidireccional entre capas, violando las reglas de MVC y volviendo directamente a la arquitectura de la cuna del gato que [presumiblemente] intentabas evitar en primer lugar.

En cambio, la clase MyCoolListControl debe ir con el flujo, extrayendo los datos que necesita de la capa de abajo, cuando lo necesita. En el caso de un widget de lista, eso generalmente significa preguntar cuántos valores hay y luego preguntar por cada uno de esos elementos a su vez, porque esa es la forma más simple y flexible de hacerlo y, por lo tanto, mantiene el acoplamiento al mínimo. Y si el widget quiere, por ejemplo, presentar esos valores al usuario en un orden alfabético agradable, entonces esa es su perogativa; y su responsabilidad, por supuesto.

Ahora, un último enigma, como indiqué anteriormente: ¿cómo mantiene sincronizada la pantalla de la interfaz de usuario con el estado del modelo en un sistema basado en MVC?

Este es el problema: muchos objetos de Vista tienen estado, por ejemplo, una casilla de verificación puede estar marcada o no, un campo de texto puede contener texto editable. Sin embargo, MVC dicta que todos los datos del usuario se almacenen en la capa Modelo, por lo que cualquier dato que posean otras capas para fines de visualización (el estado de la casilla de verificación, el texto actual del campo de texto) debe ser una copia subsidiaria de los datos primarios del Modelo. Pero si el estado del Modelo cambia, la copia de la Vista de ese estado ya no será precisa y debe actualizarse.

¿Pero cómo? El patrón MVC evita que el Modelo introduzca una copia nueva de esa información en la capa Vista. Diablos, ni siquiera permite que el Modelo envíe un mensaje a la Vista para decir que su estado ha cambiado.

Bueno, casi. De acuerdo, la capa Modelo no puede hablar directamente con otras capas, ya que hacerlo requeriría que sepa algo sobre esas capas, y las reglas MVC lo impiden. Sin embargo, si un árbol cae en un bosque y no hay nadie cerca para escucharlo, ¿suena?

La respuesta, como puede ver, es configurar un sistema de notificaciones, proporcionando a la capa Modelo un lugar que pueda anunciar a nadie en particular que acaba de hacer algo interesante. Luego, otras capas pueden publicar oyentes con ese sistema de notificación para escuchar los anuncios que realmente les interesan. La capa Modelo no necesita saber nada sobre quién está escuchando (¡o incluso si alguien está escuchando en absoluto!); solo publica un anuncio y luego lo olvida. Y si alguien escucha ese anuncio y tiene ganas de hacer algo después, como pedirle al Modelo algunos datos nuevos para que pueda actualizar su visualización en pantalla, entonces genial. El modelo solo enumera las notificaciones que envía como parte de su definición de API; y lo que alguien más haga con ese conocimiento depende de ellos.

MVC se conserva y todos están felices. El marco de su aplicación puede proporcionar un sistema de notificaciones incorporado, o puede escribir el suyo si no (vea el 'patrón de observador').

...

De todos modos, espero que eso ayude. Una vez que comprenda las motivaciones detrás de MVC, las razones por las cuales las cosas se hacen de la manera en que son comienzan a tener sentido, incluso cuando, a primera vista, parecen más complejas de lo necesario.

Salud,

tiene

MVC es principalmente una palabra de moda.

Solía ​​considerarse un patrón, pero su definición original de 1979 ha sido tonta, transmitida, malinterpretada, fuera del contexto original. Ha sido mal redefinido hasta el punto de que comienza a parecerse a una religión, y aunque esto ciertamente ayuda a sus cultistas de carga a defenderlo, su nombre ya no se asocia con un conjunto sólido de pautas . Como tal, ya no se puede considerar un patrón.

MVC nunca tuvo la intención de describir aplicaciones web.
Ni sistemas operativos modernos, ni idiomas.
(algunos de los cuales hicieron que la definición de 1979 fuera redundante)

Fue hecho para. Y no funcionó.

Ahora tratamos con un híbrido web-mvc obsceno que, con su horrible estado de palabra de moda, mala definición y tener programadores semi-analfabetos como objetivo demográfico, hace una muy mala publicidad a los patrones de software en general.

MVC, por lo tanto, se convirtió en una separación de las preocupaciones destiladas para las personas que realmente no quieren pensar demasiado en ello.

• El modelo de datos se maneja de una manera,
• la vista en otro,
• el resto solo se llama "controlador" y se deja a discreción del lector.

Los sitios web / aplicaciones web en los años 90 realmente no se usaban para aplicar la separación de preocupaciones.

Eran horribles fallas de código de espagueti entremezclado.
Los cambios de UI, rediseños y reordenamientos de datos fueron increíblemente difíciles, caros, largos, deprimentes y desafortunados.

Las tecnologías web como ASP, JSP y PHP hacen que sea demasiado fácil mezclar preocupaciones de vista con datos y preocupaciones de aplicación. Los recién llegados al campo generalmente emiten bolas de barro de código inextricables como en aquellos viejos tiempos.

Por lo tanto, un número creciente de personas comenzó a repetir "usar MVC" en bucles sin fin en los foros de soporte. El número de personas se expandió hasta el punto de incluir gerentes y especialistas en marketing (para algunos el término ya era familiar, desde aquellos tiempos en la programación gui, en la que el patrón tenía sentido) y eso se convirtió en el gigante de una palabra de moda que tenemos que enfrentar ahora. .

Tal como está, es sentido común , no una metodología .
Es un punto de partida , no una solución .
Es como decirle a la gente que respire aire o haga abdominales , no una cura para el cáncer .

La mejor manera de definirlo es ir a los escritos originales de Trygve Reenskaug , quien lo inventó: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Este documento, en particular, generalmente se considera el texto de definición: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELOS

Los modelos representan el conocimiento. Un modelo podría ser un solo objeto (más bien poco interesante), o podría ser alguna estructura de objetos ...

Debe haber una correspondencia biunívoca entre el modelo y sus partes, por un lado, y el mundo representado, tal como lo percibe el propietario del modelo, por otro lado. Por lo tanto, los nodos de un modelo deben representar una parte identificable del problema.

Todos los nodos de un modelo deben estar en el mismo nivel de problema, es confuso y se considera una mala forma mezclar nodos orientados a problemas (por ejemplo, citas de calendario) con detalles de implementación (por ejemplo, párrafos).

PUNTOS DE VISTA

Una vista es una representación (visual) de su modelo. Normalmente destacaría ciertos atributos del modelo y suprimiría otros. Por lo tanto, actúa como un filtro de presentación .

Se adjunta una vista a su modelo (o parte del modelo) y obtiene los datos necesarios para la presentación del modelo haciendo preguntas. También puede actualizar el modelo enviando mensajes apropiados. Todas estas preguntas y mensajes deben estar en la terminología del modelo, por lo tanto, la vista deberá conocer la semántica de los atributos del modelo que representa. (Puede, por ejemplo, pedir el identificador del modelo y esperar una instancia de Texto, puede no suponer que el modelo es de la clase Texto).

CONTROLADORES

Un controlador es el enlace entre un usuario y el sistema. Proporciona información al usuario al organizar vistas relevantes para presentarse en los lugares apropiados de la pantalla. Proporciona medios para la salida del usuario al presentarle al usuario menús u otros medios para dar comandos y datos. El controlador recibe dicha salida del usuario, la traduce en los mensajes apropiados y pasa estos mensajes a una o más de las vistas.

Un controlador nunca debe complementar las vistas, por ejemplo, nunca debe conectar las vistas de los nodos dibujando flechas entre ellos.

Por el contrario, una vista nunca debe saber acerca de la entrada del usuario, como las operaciones del mouse y las pulsaciones de teclas. Siempre debería ser posible escribir un método en un controlador que envíe mensajes a las vistas que reproducen exactamente cualquier secuencia de comandos de usuario.

EDITORES

Un controlador está conectado a todas sus vistas, se llaman las partes del controlador. Algunas vistas proporcionan un controlador especial, un editor , que permite al usuario modificar la información que presenta la vista. Dichos editores pueden empalmarse en la ruta entre el controlador y su vista, y actuarán como una extensión del controlador. Una vez que se completa el proceso de edición, el editor se elimina de la ruta y se descarta.

Tenga en cuenta que un editor se comunica con el usuario a través de las metáforas de la vista conectada, por lo tanto, el editor está estrechamente asociado con la vista. Un controlador obtendrá un editor pidiéndole la vista, no hay otra fuente apropiada.

MVC es un patrón de diseño utilizado para aislar la lógica empresarial de la presentación.

Se diferencia de muchos otros patrones de diseño por el hecho de que generalmente no se implementa de manera sucinta, sino que es la base de un marco.

Si bien una aplicación que implementa un patrón de Estrategia es solo un pequeño detalle al respecto, decir que una aplicación web usa el patrón de diseño MVC es muy definitorio de su arquitectura .

MVC es un diseño de software que separa los siguientes componentes de un sistema o subsistema:

1. Modelo: datos sobre el estado de la aplicación o sus componentes. Puede incluir rutinas para modificación o acceso.
2. Ver: una interpretación de los datos (modelo). Esto solo se limita a una representación visual, pero podría ser audio, información derivada (por ejemplo, estadísticas canalizadas a otro objeto modelo), etc. Además, un solo modelo puede tener múltiples vistas.
3. Control: maneja la entrada externa al sistema invocando modificaciones en el modelo. El control / vista puede estar estrechamente relacionado (en el caso de una IU). Sin embargo, se pueden procesar otras entradas externas (como los comandos de red), que son completamente independientes de la vista.

Diría que MVC es un concepto o una familia de patrones similares.

Creo que vale la pena leer este artículo. Arquitecturas GUI por Martin Fowler

Primero, debe determinar quién es el que hace la pregunta y qué tipo de respuesta está buscando. Respondes a esta pregunta con otra pregunta, como "¿En qué sentido?"

Puede preguntar si se refieren a MVC en general, una implementación particular de MVC (es decir, asp.net MVC, spring MVC, smalltalk MVC, etc.), qué es técnicamente, qué es filosóficamente (sí, tiene un filosofía también), etc.

Si esta es una pregunta en una prueba, y no puede pedirle al autor de la pregunta que aclare, entonces tendrá que adivinar según el contexto.

Una buena respuesta simple es:

MVC es una arquitectura de interfaz de usuario de software utilizada para separar las preocupaciones estructurales y de comportamiento con el fin de facilitar un software más mantenible.

También puede decir:

Al separar la Vista del Controlador del Modelo, fomenta el aislamiento de los componentes en función de sus responsabilidades. En teoría, y generalmente en la práctica, esto ayuda a mejorar la capacidad de mantenimiento al evitar que las diferentes partes del sistema se mezclen y creen sistemas más complejos.

Pero, al final, se te juzgará si das la respuesta que esperan. La única solución al problema es averiguar qué tipo de respuesta esperan.

Esto es lo que diría al respecto. Trataría de explicarlo en términos de aplicaciones móviles, porque es con lo que estoy más familiarizado y porque no creo haberlo entendido completamente antes de comenzar a hacer aplicaciones móviles.
Tomemos Android por ejemplo.
Capa de presentación, es decir. La interfaz de usuario puede (debería, la mayoría de las veces) especificarse completamente en xml. Por simplicidad, digamos que un archivo xml describe una pantalla en la aplicación. El archivo XML especifica controles, diseño de los controles, posicionamiento, colores, tamaño, etiquetas de cadena ... todo lo relacionado con la presentación. Sin embargo, no sabe nada sobre cuándo se llamará, cuándo se colocará en la pantalla. ¿Será un diseño independiente o parte de un diseño más grande? Ahí lo tienes: tu VISTA perfecta .

Ahora, obviamente, la vista debe colocarse en la pantalla en algún momento, entonces, ¿cómo debería hacerlo? Su CONTROLADOR , en Android llamado Actividad. Como su nombre lo dice, la actividad hace algo de actividad. Incluso si su único propósito es mostrar la vista definida en el paso 1, realizará alguna acción. Entonces, la actividad obtiene una vista y la muestra en la pantalla. Como la vista no sabe nada acerca de la actividad, la actividad tampoco sabe nada acerca de la presentación real. Nosotros (los programadores) podríamos reorganizar el diseño de la vista varias veces, sin cambiar ni una sola línea de código en nuestra actividad.

Ahora, no tiene mucho uso presentar su bonito diseño brillante y bien definido de XML sin hacer algo realmente. Digamos que queremos almacenar los datos ingresados ​​por el usuario. La actividad debe abordar este proceso, desde tomar los datos del usuario hasta pasarlos a otra persona para que los maneje (procesar, almacenar, eliminar). ¿A quién le pasará? Bueno, a un MODELO . Me gusta pensar que una modelo es pura. clase de Java que no sabe nada sobre el contexto de aplicación en el que vive. (En la práctica, ese casi nunca será el caso).

Digamos que tengo una clase Persona que tiene tres propiedades: nombre, dirección, edad. Mi diseño definido por XML tiene 3 campos para la entrada del usuario: nombre, dirección, edad. Mi actividad toma los tres valores de la entrada del usuario, crea un nuevo objeto Person e invoca algún método que sepa cómo manejar una lógica específica de Person. Ahí tienes. Modelo-Vista-Controlador.

Siempre empiezo diciéndoles que el patrón no es nada nuevo y que ha existido durante muchos años ... es en este punto que me dan una mirada inquisitiva y ¡BAM !, están enganchados:

Y luego hablaría sobre los diversos puntos, como las respuestas anteriores, pero creo que también es importante ser contextual, como dijo JB King, ASP.NET MVC, etc.