Quel diagramme MVC est correct? (Application Web)
Quel diagramme MVC est correct? Chacun a des flèches différentes ...
Schéma 1
Schéma 2
http://blog.stannard.net.au/blog/media/simple-mvc-framework/mvc.gif
Schéma 3
Schéma 4
http://Java.Sun.com/blueprints/patterns/images/mvc-structure-generic.gif
Schéma 5
Ils sont tous.
MVC est un modèle vague.
Mon point de vue sur MVC est le suivant:
Manette
Object contient une collection de modèles et des méthodes pour afficher et éditer les modèles. Il communique avec les modèles et renvoie des instances de vues contenant des modèles.
Vue
A la définition d'un modèle qui lui est attaché et est juste un ensemble de fonctionnalités pour afficher un modèle spécifique.
Modèle
Encapsule les données. Possède des méthodes pour retourner l'état et changer d'état.
//Controller
import Views
class Controller
private Models
//View
import Model
class View
//Model
class Model
Un modèle n'a besoin de rien savoir de la vue/du contrôleur. Une vue doit connaître la définition d'un modèle. Un contrôleur doit posséder des modèles et doit connaître les définitions des vues.
Vous pouvez les coupler plus étroitement, c'est facultatif.
MVC, à proprement parler, est une sorte de schéma obsolète. Parlant grossier, il introduit des dépendances entre View et Model, puisque Model met à jour le statut View... ( http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC. htm ), comme indiqué dans le diagramme 4, où vous voyez une interaction directe entre Modèle et Vue, conformément à la formulation historique et originale de MVC, ce qui n'est pas souhaitable. En fait, nous avons aujourd'hui modifié les versions de MVC, et parfois nous décrivons MVP et l'appelons MVC. L'acronyme "MVC" a été utilisé avec tellement de liberté que tout élément comportant trois éléments appelés Modèle, Vue et Contrôleur est essentiellement MVC, malgré les détails d'implémentation et les définitions de responsabilité. La différence est vraiment subtile entre MVC et MVP, lorsque vous les décrivez, et réside dans la définition des responsabilités View and Presenter (Controller). En fait, Martin Fowler a fait ses adieux à MVP (et à MVC) il y a quelques années ( http://www.martinfowler.com/eaaDev/ModelViewPresenter.html ), et nous pouvons trouver, de son côté, la définition d’un "nouveau" modèle appelé Modèle de présentation (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 a pour modèle de présentation son inspiration. Je pense que vous pouvez jeter un coup d'œil à tous ces gars et déterminer à quel point ils sont semblables (et différents). À mon humble avis, l'idée de base est que les données et le comportement de la présentation restent dans Presenter, que Model ne sache pas la vue (donc le diagramme 4 est éteint, même en étant MVC) et que vous devriez pouvoir changer de vue (ou prendre en charge une vue différente. implémentations) de manière indolore, découplée de Presenter et de Model. Presentation Model peut fournir cela et est efficace et minutieux à mettre en œuvre en utilisant les technologies actuelles.
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 n'est pas conscient de son utilisation dans MVC.
Les premier et quatrième diagrammes représentent MVC avec modèle actif.
Plus à ce sujet, vous pouvez lire ici .
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 modifications sont extraites de la vue à partir du modèle, au lieu d'être poussées par le modèle (modèle Observer).
Les diagrammes 2, 3 et 5 sont précis pour MVC. Lorsque vous envoyez une demande à un contrôleur, celui-ci exécute une opération à l'aide de modèles puis répond en retour.
Aucune d'entre elles n'est en fait erronée, mais il existe une approche différente pour MVC basé sur le Web (demande/réponse) et MVC côté client.
Dans un environnement Web, un contrôleur est responsable du traitement de la demande d'un utilisateur, de la modification du modèle (le cas échéant), de la recherche de la vue appropriée, de l'affectation des informations de ce modèle à la vue et de la restitution à l'utilisateur.
Dans l'interprétation plus directe du modèle MVC d'origine (applications de bureau parlées), le modèle met à jour la vue directement, chaque fois qu'il change, et le contrôleur gère l'entrée utilisateur et la logique d'application en mettant à jour le modèle. Cela ne fonctionne cependant pas pour les applications Web normales, puisque HTTP est sans état et n'utilise aucune autre technologie plus récente (comme les longues interrogations Ajax ou les websockets mentionnées dans le commentaire), le serveur ne peut pas vraiment informer le client des modifications apportées au modèle. .
Le diagramme 1 est la représentation correcte du motif MVC.
Les lignes continues représentent une référence réelle, comme dans une variable. Ce qui signifie que vous devriez vous attendre à voir une instance du modèle à la fois dans la vue et dans le contrôleur.
Les lignes en pointillés représentent les invocations de fonctions ou les messages de l’une à l’autre. La ligne en pointillés du modèle à la vue est implémentée via le modèle Observer, où quelque chose a changé sur le modèle et il est référencé à la vue (via l'API du observateur du modèle) où elle appelle une méthode. Quelque chose comme observer[i].update("name", value, self) qui serait appelé dans le modèle chaque fois que quelque chose change.
La ligne en pointillés entre la vue et le contrôleur est la vue qui envoie un message au contrôleur. Imaginez un bouton sur une interface utilisateur sur laquelle vous avez cliqué. Le contrôleur écoute cet événement et le gère.
Un exemple de flux de communication serait le bouton sur lequel vous avez cliqué: La vue envoie un message au contrôleur. Le contrôleur gère cet événement, où il met à jour son instance du modèle, par exemple model.name. Model a une méthode setter qui met à jour la name et appelle une méthode telle que changed qui parcourt ensuite ses observateurs et appelle .update sur chaque observateur. La vue précédemment subscribed du modèle et update y est appelée avec les anciennes et nouvelles valeurs de name. Une méthode update dans View met à jour la valeur du nom dans label. Terminé. 
Support de diapositives décrivant MVC: https://pl.csie.ntut.edu.tw/~ctchen/pdf/InsideSmalltalkMVC-public.pdf
Article du C2 sur le wiki Wiki: http://wiki.c2.com/?ModelViewController