En una arquitectura MVC, ¿qué tan cerca están el modelo y la vista del controlador?

El controlador controla el flujo de actividad. El usuario realiza esta acción, el controlador pasa los datos de la vista al dominio que hace lo que tiene que hacer en ese momento, según las respuestas, el controlador le indica al marco qué vista debe mostrar a continuación (y le da suficiente información para hacer). así).

Por lo tanto, el controlador debe estar acoplado al modelo de dominio, hasta cierto punto. es decir. Podría poner una capa de servicio en el medio pero, por definición estricta, se convierte en parte del dominio.

También está acoplado a los datos de vista, pero no a la vista en sí. es decir. simplemente dice "mostrar la vista del cliente usando este detalle del cliente". El marco entonces decide dónde debería encontrar esa vista.

Ahora, esto debería permitirle desacoplar el modelo de dominio de la vista, usando un modelo de vista de los mismos datos. Algunos desarrolladores hacen esto, otros no, y creo que es en gran medida una cuestión de preferencia personal.

En Rails, se recomienda encarecidamente que empuje los objetos del dominio (ActiveRecord) a la vista y confía en que la vista no aproveche ese acceso (por ejemplo, no debe llamar a los clientes. guardar desde la vista, aunque estaría disponible).

En el mundo .NET, tendemos a reducir el riesgo al no permitir que no sucedan cosas y, posiblemente por ese motivo, me parece que el modelo de vista independiente es más popular.

Nota: Robert C. Martin (también conocido como tío Bob) explica esto de una manera mucho mejor y divertida en su nota clave, Architecture the Lost Years . Un poco largo pero enseña muchos buenos conceptos.

tl; dr: No piense ni planifique su aplicación en términos de MVC. El marco MVC es solo un detalle de implementación.

Lo más confuso de MVC es que los desarrolladores intentan usar todos los componentes pegados.

Intente pensar en los términos de un programa, no en los términos del marco.

Su programa tiene un propósito. Toma algunos datos, hace cosas con los datos y devuelve algunos datos.

De esa manera, el controller es el mecanismo de entrega de su programa.

1. Un usuario envía una solicitud a su programa (digamos, agregue un producto al carrito de compras).
2. El controlador toma esa solicitud (información del producto e información del usuario), llama a la parte necesaria de su programa que manejará esta solicitud $user->addToCart($product)
3. Su programa (la función addToCart del objeto user en este caso) hace el trabajo que pretende hacer y devuelve una respuesta (digamos success )
4. El controlador prepara la respuesta usando el view relevante: por ejemplo. en el objeto controlador $this->render($cartView('success')

De esta manera, los controladores se desacoplan del programa y se utilizan como mecanismo de entrega. No saben cómo funciona su programa, solo saben a qué parte del programa se debe llamar para las solicitudes.

Si desea utilizar otro marco, su aplicación no necesitará un cambio, solo tendrá que escribir los controladores relevantes para llamar a su programa y solicitar solicitudes.

O si desea crear una versión de escritorio, su aplicación seguirá siendo la misma, solo necesitará preparar un mecanismo de entrega.

Y el Model . Piense en ello como un mecanismo de persistencia.

En el modo OO, hay objetos en tu programa que contienen los datos.

class User {
    //...
    private $id;
    private $shoppingCart;
    //...
}

class Product {
    //...
    private $id;
    //...
}

Cuando agrega un producto al carro de la compra, puede agregar el product::id al user::shoppingCart .

Y cuando desee conservar los datos, puede usar la parte model del marco, que generalmente consiste en usar un ORM, para asignar las clases a las tablas de la base de datos.

Si desea cambiar el ORM que usa, su programa seguirá siendo el mismo, solo cambiará la información del mapeo. O si desea evitar todas las bases de datos, solo puede escribir los datos en archivos de texto sin formato, y su aplicación seguirá siendo la misma.

Entonces, escribe tu programa primero. Si está programando con el modo 'OO', use objetos antiguos del lenguaje. No pienses en términos de MVC al principio.

Martin Fowler hace un buen trabajo al describir el paradigma MVC. Aquí hay un enlace a su artículo en él enlace

Tenga en cuenta su cita sobre la presentación separada "La idea detrás de la presentación separada es hacer una división clara entre los objetos de dominio que modelan nuestra percepción del mundo real y los objetos de presentación que son los elementos de la GUI que vemos en la pantalla".

Este es un ejemplo simple de cómo se puede usar MVC en una aplicación típica de Java Swing ...

Supongamos que tiene un panel que contiene un botón y un campo de texto. Cuando se presiona el botón, se dispara un evento, lo que lleva a un cambio de estado en la aplicación. Una vez que se registra el cambio de estado, TextField se desactiva.

Este, entonces, sería el enfoque típico adoptado por una aplicación MVC simple ...

El controlador se registra a sí mismo como el oyente de los eventos de la vista. Cuando se hace clic en el botón, la vista en sí misma no controla el evento; el controlador hace El controlador es específico para Swing, ya que debe tratar con eventos relacionados con Swing.

El controlador recibe esta notificación y debe decidir quién debe manejarlo (la vista o el modelo). Dado que este evento cambiará el estado de la aplicación, decide enviar la información al Modelo, quien es responsable de los datos y la lógica del programa. Algunos cometen el error de colocar la lógica del programa en el Controlador, pero en la POO, los Modelos representan tanto los datos como el comportamiento. Lee a Martin Fowler en su versión de esto.

El modelo recibe el mensaje en el contexto adecuado. Es decir, está completamente vacío de cualquier referencia a Swing o cualquier otra referencia de GUI específica. Este mensaje habla al modelo y SOLO al modelo. Si se encuentra importando instrucciones javax.swing en el Modelo, no está codificando el Modelo correctamente.

El modelo luego establece su estado en 'deshabilitado' y procede a notificar a las partes interesadas de este cambio de modelo. La vista, al estar interesado en este evento, ya se ha registrado como un observador de cualquier cambio de modelo. Una vez que la vista recoge el evento de cambio de estado del modelo, se procede a deshabilitar su campo de texto. También es legal que la Vista obtenga información de solo lectura directamente de su Modelo sin tener que pasar por el Controlador (generalmente a través de una interfaz específica expuesta por el Modelo para dicha actividad)

Al promover un acoplamiento tan suelto entre la Presentación y la lógica de negocios y las capas de datos, encontrará que su código es mucho más fácil de mantener. A medida que los sistemas crecen, también lo hará su enfoque de MVC. Por ejemplo, Jerárquico MVC es una extensión que se usa a menudo para vincular las tríadas MVC entre sí para formar grandes sistemas en toda la empresa sin acoplar subsistemas

El acoplamiento (el tipo que desea evitar) implica una dependencia mutua entre dos clases. Es decir, un Foo depende de una Barra y un Bar depende de un Foo para que no pueda modificar uno sin modificar el otro. Eso es algo malo.

Sin embargo, no puedes evitar tener ALGUNAS dependencias. Las clases tienen que saber un poco la una de la otra, de lo contrario nunca se comunicarían.

En el patrón MVC, el Controlador controla la comunicación entre el Modelo de dominio y la Vista de presentación. Como tal, el Controlador debe saber lo suficiente sobre el Modelo para pedirle que haga lo que se supone que debe hacer. El Controlador también debe saber lo suficiente sobre la Vista para poder presentarla al cliente o usuarios. Por lo tanto, el controlador Model tiene dependencias en ambos. Sin embargo, la Vista puede existir perfectamente bien sin el Controlador, no hay dependencia allí. Del mismo modo, el modelo no tiene dependencias en el controlador, simplemente es lo que es. Finalmente, el modelo y la vista están completamente separados unos de otros.

Esencialmente, el controlador es el nivel de direccionamiento indirecto que desacopla la vista del modelo, de modo que no tienen que conocerse entre sí.

En mi experiencia, generalmente el modelo solo depende de la vista a , no específica, a menudo como observador ... si tiene algún tipo de acoplamiento de este tipo.

La vista generalmente se acopla a lo que sea que esté mirando, lo que tiene sentido. Es difícil encontrar una vista que se pueda desacoplar de lo que está viendo ... pero a veces puedes tener un acoplamiento parcial o algo así.

El controlador a menudo tiende a acoplarse a ambos. Esto también tiene sentido, ya que su trabajo es convertir los eventos de vista en cambios de modelo.

Por supuesto, esta es solo una tendencia que he observado y realmente no dice nada sobre ningún ejemplo específico.

Para comprender qué es MVC y cuál es la relación de acoplamiento, debería ver cómo se creó MVC. El entorno en el que se creó MVC fue uno en el que no existían "widgets" como elementos de formulario con los que puede crear diálogos. Una "vista" era una caja y dibujaba cosas. Una vista de texto sería un cuadro que dibujaría texto. Una vista de lista era un cuadro que dibujaría una lista. El "controlador" recibió todos los eventos del mouse y el teclado del sistema UI que tuvieron lugar en esa vista; no hubo eventos "textChanged" o "selectionChanged". El controlador tomaría todos estos eventos de bajo nivel y generaría interacción con el modelo. El modelo, al ser modificado notificará sus puntos de vista; Desde entonces, hemos llegado a ver esta relación como "observador" y se usa de otras maneras como su propio patrón.

Esa es la esencia del patrón MVC. Dado que este tipo de programación de IU de bajo nivel generalmente no se realiza más, el MVC ha evolucionado en muchas direcciones diferentes. Algunas de las cosas que llevan ese nombre hoy en día no se parecen en nada al MVC y realmente deberían llamarse otra cosa. Todavía se puede utilizar aunque en el sentido de un diálogo en su conjunto interactuando con un objeto más grande. Sin embargo, hay muchas mejores alternativas.

Básicamente, todo lo que MVC debía resolver ahora ocurre dentro de los widgets ahora y es algo que ya no tenemos que usar.

Para aquellos que piensan que saben más:

enlace

enlace

Estoy seguro de que hay más, pero esos son solo los primeros lugares de la lista en google. Como puede ver, el modelo depende en gran medida de una interfaz de vista en MUCHAS implementaciones. En general, un modelo es observable y la vista es un observador.

Pero ¿por qué dejar que los hechos se interpongan en el camino ...

Un artículo ya publicado en otra respuesta también respalda mis declaraciones:

enlace

Si la gente quiere continuar diciendo que TODOS en la industria del diseño están equivocados, está bien.

• El controlador envía el modelo a una vista y procesa el modelo enviado desde las vistas, sin embargo, no está estrechamente acoplado a una vista o modelo.

Si el controlador estaba estrechamente acoplado a una vista, entonces estaremos en un mundo de formularios web. Tendría un código detrás que estaría vinculado a un archivo de plantilla (aplicable a los formularios web de ASP.NET)

Debido a esto, el controlador no está acoplado a un modelo o una vista. Es solo un mecanismo para procesar solicitudes y enviar respuestas.

• La vista está estrechamente unida a un modelo. Realice cambios en su modelo (por ejemplo, cambie su propiedad) y tendrá que realizar cambios en su vista.

• El modelo no está estrechamente acoplado a una vista. Realice cambios en una vista y no afectará a un modelo.

• El modelo no sabe nada sobre el controlador o las vistas donde se puede usar. Por lo tanto, el modelo no está estrechamente acoplado a una vista o controlador.

Otra forma de pensar sobre esto:

• Realice cambios en un controlador: la vista y el modelo no se verán afectados

• Realice cambios en un modelo: la vista se interrumpirá porque se basa en un modelo

• Realice cambios en una vista: el modelo y el controlador no se verán afectados

Este acoplamiento suelto en los proyectos MVC es lo que los hace fáciles de probar por unidad.