¿Qué diagrama de MVC es correcto? (Aplicación web)

Question

¿Qué diagrama de MVC es correcto? Cada uno tiene diferentes flechas ...

Diagrama 1

Diagrama Diagrama 2

http://blog.stannard.net.au/blog/media/simple-mvc-framework/mvc.gif

Diagrama 4

http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif

Diagrama 5

http://www.shopno-dinga.com/dustbin/mvc.png

Answer 1

Todos lo son.

MVC es un patrón vago.

Mi opinión sobre MVC es que:

controlador

objeto tiene una colección de modelos y tiene métodos para visualizar y editar los modelos. Habla con Modelos y devuelve instancias de Vistas con modelos aplicados en ellos.

Ver

tiene la definición de un modelo que se adjunta a la misma y es sólo un conjunto de funcionalidades para mostrar un modelo específico.

Modelo

encapsula datos. Tiene métodos para devolver el estado y cambiar el estado.

//Controller 
import Views 

class Controller 
    private Models 

//View 
import Model 

class View 

//Model 
class Model 

Un modelo no necesita saber nada sobre la Vista/Controlador. Una vista necesita conocer la definición de un modelo. Un controlador necesita propios modelos y necesita conocer las definiciones de Vistas.

Puede acoplarlos con más fuerza, eso es opcional.

Answer 2

De hecho, hay una pequeña diferencia.

Hay dos tipos de modelos: Modelo activo y Modelo pasivo: el primero tiene un mecanismo de notificación y el segundo simplemente no es consciente de su uso en MVC.

Primero y cuarto diagramas representan MVC con modelo activo.

Más sobre esto puedes leer here.

Answer 3

Ninguno de ellos es realmente incorrecto, pero hay un enfoque diferente para MVC basado en la web (solicitud/respuesta) y MVC del lado del cliente.

En un entorno web, un controlador es responsable de atender una solicitud de los usuarios, modificar el modelo (si corresponde), encontrar la vista correcta, asignar esa información de modelo a la vista y devolverla al usuario.

En la interpretación más directa del patrón MVC original (aplicaciones de escritorio speak) el modelo actualiza la vista directamente, cada vez que cambia, y el controlador trata con la entrada del usuario y la lógica de aplicación actualizando el modelo en consecuencia. Sin embargo, esto no funciona para las aplicaciones web normales, ya que HTTP es sin estado y sin utilizar ninguna tecnología más reciente (como Ajax o websockets de larga data como se menciona en el comentario), el servidor no puede notificar al cliente acerca de los cambios en el modelo .

Answer 4

Los diagramas 1 y 4 son patrones MVC correctos. El resto está más cerca del patrón MVP.

Aunque en un MVC web tiene un modelo pasivo y los cambios son sacados por la vista desde el modelo, en lugar de ser impulsados ​​por el modelo (patrón de observador).

Answer 5

MVC, estrictamente hablando, es un patrón obsoleto. Hablando groseramente, introduce dependencias entre Ver y Modelo, ya que el Modelo actualiza el estado Ver directamente (http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm), como se muestra en el diagrama 4, donde ve la interacción directa entre el Modelo y la Vista, según MVC original, formulación histórica, y esto no es deseable De hecho, hoy tenemos versiones modificadas de MVC, y algunas veces describimos MVP y lo llamamos MVC. El acrónimo "MVC" se ha utilizado con tanta libertad que todo lo que tiene tres elementos llamados Modelo, Vista y Controlador es básicamente MVC, a pesar de los detalles de implementación y las definiciones de Responsabilidad. La diferencia es realmente sutil entre MVC y MVP, cuando los describes, y reside en la definición de responsabilidades de Vista y Presentador (Controlador). Martin Fowler, de hecho, dio su adiós a MVP (y MVC) hace algunos años (http://www.martinfowler.com/eaaDev/ModelViewPresenter.html), y podemos encontrar, por su parte, la definición de un "nuevo" patrón llamado Presentation Model (ver http://martinfowler.com/eaaDev/PresentationModel.html), o PM. Microsoft ha definido para sus tecnologías WPF y Silverlight otro patrón, llamado Modelo-Vista-Vista-Presentador, o MVVM (vea http://msdn.microsoft.com/en-us/magazine/dd419663.aspx), que tiene el Modelo de Presentación como su inspiración. Creo que puedes echar un vistazo a todos estos tipos y calcular lo parecidos (y diferentes) que son. En mi humilde opinión, la idea básica es que los datos y el comportamiento de la presentación permanecen en el presentador, el modelo no conoce la vista (por lo que el diagrama 4 está desactivado, aunque también es MVC), y usted debería poder cambiar la vista (o implementaciones) de una manera indolora, desacoplada tanto del presentador como del modelo. Presentation Model puede proporcionar esto y es efectivo y exhaustivo para implementar utilizando las tecnologías actuales.

Answer 6

Los diagramas 2, 3 y 5 son precisos para MVC. Cuando envía una solicitud a un controlador, realiza la operación usando modelos y luego responde de nuevo.