Quel est le bon diagramme MVC pour une application web ?

Question

Quel diagramme MVC est correct ? Chacun a des flèches différentes...

Diagramme 1

Diagramme 2

_{(source : <a href="http://blog.stannard.net.au/blog/media/simple-mvc-framework/mvc.gif" rel="noreferrer">stannard.net.au </a>)}

Diagramme 3

Diagramme 4

_{(source : <a href="http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif" rel="noreferrer">soleil.com </a>)}

Diagramme 5

_{(source : <a href="http://www.shopno-dinga.com/dustbin/mvc.png" rel="noreferrer">shopno-dinga.com </a>)}

Answer 1

Ils le sont tous.

MVC est un modèle vague.

Mon point de vue sur MVC est que :

Contrôleur

Object possède une collection de modèles et dispose de méthodes pour visualiser et modifier les modèles. Il communique avec les modèles et renvoie des instances de vues avec des modèles appliqués sur elles.

Voir

La définition d'un modèle y est attachée et il s'agit simplement d'un ensemble de fonctionnalités permettant d'afficher un modèle spécifique.

Modèle

Encapsule les données. Possède des méthodes pour retourner l'état et changer l'état.

//Controller
import Views

class Controller
  private Models

//View
import Model

class View

//Model
class Model

Un modèle n'a pas besoin de savoir quoi que ce soit sur la vue ou le contrôleur. Une vue a besoin de connaître la définition d'un modèle. Un contrôleur doit propre Modèles et doit connaître les définitions des vues.

Vous pouvez les coupler plus serré, c'est facultatif.

Answer 2

MVC, à proprement parler, est une sorte de modèle dépassé. Grossièrement parlant, il introduit des dépendances entre la vue et le modèle, puisque le modèle met à jour l'état de la vue directement ( http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm ), comme le montre le diagramme 4, où l'on voit une interaction directe entre le modèle et la vue, selon la formulation originale et historique de MVC, ce qui n'est pas souhaitable. En fait, nous avons aujourd'hui des versions modifiées de MVC, et parfois nous décrivons MVP et l'appelons MVC. L'acronyme "MVC" a été utilisé avec tellement de liberté que tout ce qui comporte trois éléments appelés Modèle, Vue et Contrôleur est fondamentalement MVC, malgré les détails de mise en œuvre et les définitions de responsabilité. La différence est vraiment subtile entre MVC et MVP, lorsqu'on les décrit, et réside dans la définition des responsabilités de la vue et du présentateur (contrôleur). Martin Fowler, en fait, a fait ses adieux à MVP (et MVC) il y a quelques années ( http://www.martinfowler.com/eaaDev/ModelViewPresenter.html ), et on trouve, de son côté, la définition d'un "nouveau" modèle appelé Presentation Model (voir http://martinfowler.com/eaaDev/PresentationModel.html ), ou PM. Microsoft a défini pour ses technologies WPF et Silverlight un autre modèle, appelé Model-View-View-Presenter, ou MVVM (voir http://msdn.microsoft.com/en-us/magazine/dd419663.aspx ), qui s'inspire du modèle de présentation. Je pense que vous pouvez jeter un coup d'œil à tous ces types et vous rendre compte à quel point ils sont semblables (et différents). A mon humble avis, l'idée de base est que les données et le comportement de la présentation restent dans le Presenter, que le modèle ne connaît pas la vue (donc le diagramme 4 est faux, même s'il s'agit d'un MVC), et que vous devriez être capable de changer la vue (ou de supporter différentes implémentations de vue) d'une manière simple, découplée du Presenter et du modèle. Le modèle de présentation peut fournir cela et est efficace et complet à mettre en œuvre en utilisant les technologies actuelles.

Answer 3

En fait, il y a une petite différence.

Il existe deux types de modèles : Modèle actif et Modèle passif : le premier dispose d'un mécanisme de notification et le second ne sait pas être utilisé dans MVC.

Les premier et quatrième diagrammes représentent MVC avec Active Model.

Pour en savoir plus, vous pouvez lire aquí .

Answer 4

Les diagrammes 1 et 4 sont des modèles MVC corrects. Les autres sont plus proches du modèle MVP.

Cependant, dans un MVC web, vous avez un modèle passif et les changements sont tirés du modèle par la vue, au lieu d'être poussés par le modèle (modèle Observer).

Answer 5

Aucune d'entre elles n'est réellement fausse, mais il existe une approche différente pour le MVC basé sur le Web (demande/réponse) et le MVC côté client.

Dans un environnement Web, un contrôleur est chargé de traiter la demande d'un utilisateur, de modifier le modèle (le cas échéant), de trouver la bonne vue, d'affecter les informations du modèle à la vue et de la renvoyer à l'utilisateur.

Dans l'interprétation plus directe du modèle MVC original (pour les applications de bureau), le modèle met à jour la vue directement, à chaque fois qu'il est modifié, et le contrôleur s'occupe de l'entrée de l'utilisateur et de la logique applicative en mettant à jour le modèle en conséquence. Cela ne fonctionne pas pour les applications web normales, puisque HTTP est sans état et que sans l'utilisation d'une autre technologie plus récente (comme le long polling Ajax ou les websockets comme mentionné dans le commentaire) le serveur ne peut pas vraiment notifier le client des changements dans le modèle.