J'essaie conceptuellement de comprendre si je dois faire ceci:
item = Model()
screen = View()
brain = Controller(item, screen)
ou ca..
brain = Controller()
item = Model(brain)
screen = View(brain)
ou ca..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
ou autre chose entièrement?
Réponses:
Pour moi, la première option est logique. Le travail du contrôleur est de coordonner la vue et le modèle. De ce point de vue, il est logique que le contrôleur soit celui qui contrôle les références à la vue et au modèle.
Vous ne pouvez pas vraiment avoir un contrôleur sans un modèle et une vue, mais il est beaucoup plus logique de simplement avoir une vue ou simplement un modèle (par exemple, dans les tests unitaires). C'est pourquoi vous souhaitez transmettre ces dépendances au contrôleur, et non aux deux autres.
Les Modelet Viewsont indépendants les uns des autres.
Ne considérez pas le Controllercomme le cerveau de la structure MVC. Considérez-le comme le répartiteur qui gère les demandes du navigateur et les envoie au Model. Il prend ensuite les données de l ' Modelet les empaquette dans un modèle convivial, puis les envoie à a View.
C'est Modelle cerveau de la structure MVC, et c'est là que vous devez mettre vos règles commerciales. Les règles métier sont communes à plusieurs contrôleurs . Ainsi, un contrôleur de documents et un contrôleur de rapports peuvent tous deux utiliser un modèle utilisateur pour voir qui a accès à ces choses. Vous ne voudriez pas répéter ces règles dans les deux contrôleurs.
Le Viewdoit utiliser un modèle HTML pour présenter les données d'une manière non spécifique à la source de données. Il ne doit pas être étroitement lié au schéma de votre base de données. Pour afficher le titre d'un document, la vue afficherait le contenu d'une variable de modèle appelée document_title, et seul le Controllersait comment cette variable a été définie, et seul le Modelsait pourquoi ce document a ce titre.
MVC a été initialement défini pour faciliter la programmation des applications de bureau. La vue s'est abonnée aux événements du modèle, mettant à jour la présentation lorsque le modèle a changé. Le contrôleur a simplement traduit les événements de l'interface utilisateur (par exemple, une pression sur un bouton) en appels au modèle. Le contrôleur et la vue dépendaient donc du modèle, mais étaient indépendants l'un de l'autre. Le modèle était indépendant des deux. Cela a permis à plusieurs vues et contrôleurs de fonctionner sur le même modèle.
L'architecture "MVC" utilisée pour les applications Web 1.0 (actualisation de la page complète, pas d'AJAX) est quelque peu différente. Une demande Web est envoyée à un contrôleur. Le contrôleur modifie en quelque sorte l'état du modèle, puis envoie un ou plusieurs modèles à restituer par une vue. Le contrôleur et la vue dépendent tous deux du modèle, mais le contrôleur dépend également de la vue.
Avec les applications web 2.0, nous revenons à l'architecture MVC classique, côté client . Le modèle, la vue et le contrôleur résident tous du côté client en tant qu'objets Javascript. Le contrôleur traduit les événements utilisateur en actions de modèle. Les actions du modèle peuvent ou non entraîner une demande AJAX au serveur. Encore une fois, la vue s'abonne aux événements de modèle et met à jour la présentation en conséquence.
La vue doit s'abonner aux modifications du modèle. Il y a une latitude dans la richesse des abonnements car ils peuvent être détaillés (montrez-moi les changements d'inventaire pour cet article particulier) ou génériques (le modèle a changé); la vue peut interroger le modèle en réponse à une notification de modification. La vue présente l'ensemble souhaité d'éléments de modèle à l'écran, mettant à jour l'écran comme lors de la gestion des notifications de modification.
Le contrôleur doit pousser les modifications apportées au modèle, en fonction de la direction de l'utilisateur (par exemple, clavier en entrée, souris et commandes de menu).
Le modèle conserve le modèle et une liste des abonnements et doit notifier les vues des modifications applicables via leurs abonnements.
Il doit également y avoir un mécanisme pour créer de nouvelles vues et contrôleurs (car dans MVC, vous devriez pouvoir avoir deux ou plusieurs vues du même modèle (elles peuvent être la même vue (point) ou des vues (point (s) différentes)). Logiquement, nous pouvons considérer que le contrôleur doit fonctionner ou avoir accès à une usine de visualisation et de contrôleur (paire), qui peut faire partie du contrôleur ou d'un autre composant.
Modelsne notifie pas Views. Controllersrecherchez les Modelmodifications, puis effectuez un rendu Viewspour présenter ces modifications.
MVC ressemble plus à un modèle de modularité. Son objectif est que chaque fois que vous souhaitez modifier la disposition de l'interface utilisateur (vue), vous n'avez pas à modifier la logique d'application (contrôleur) ou les traitements de données internes (modèle).
Pour y parvenir, le modèle consiste à isoler la logique d'implémentation de chaque composant MVC. Pourtant, il est parfaitement normal que les composants connaissent les interfaces les uns des autres .
Ce que j'ai souvent vu, c'est que le contrôleur crée ou appelle un modèle et une vue (donc il connaît leur interface) et qu'un modèle ou une vue peut notifier le contrôleur en retour (plus comme un rappel ou un modèle d'observateur). La partie importante est que le contrôleur n'est pas au courant de la structure de la disposition.