Où est le M dans MVC?

Question

La question que je vais poser a été inspirée par mon dernier travail avec la plate-forme Flex (et certains frameworks prétendant implémenter MVC), mais je pense que c'est assez général pour impliquer des gens avec des expertises diverses.

Pour beaucoup de temps, je l'ai suivi les paradigmes, proposés par des cadres comme Cairngorm -

Voir, lié aux propriétés d'un modèle singleton et événements dispatching. Les événements sont interceptés par le contrôleur frontal et les commandes sont exécutées en conséquence. Les commandes permettent d'appeler des services, d'obtenir des données et de fournir le modèle. Le modèle met implicitement à jour les vues via des liaisons.

Il était tout agréable et son jusqu'à ce que je suis arrivé à la structure de données suivantes:

utilisateur a de nombreux adeptes (utilisateurs) suit de nombreux utilisateurs a un tas de photos suit de nombreux endroits

photo a beaucoup likers (User) dispose d'un emplacement a un créateur a de nombreuses photos liées

Locatio n a de nombreuses photos a de nombreux adeptes

Encore une fois, il ne serait pas un problème à utiliser l'idée proposée par Cairngorm, par exemple d'avoir un currentUser, CurrentLocation et currentPhoto, et juste se lier à eux.

Le problème vient dans les vues elles-mêmes. J'ai une série de vues "page" complexes, qui fournissent des informations comme on pourrait l'imaginer. Par exemple, la page de localisation, montre une grille de photos récentes/populaires, un panneau pour les adeptes, et une carte basée sur les coordonnées où ces photos ont été prises. Voici les problèmes:

Évidemment, pour des raisons de performances, je ne peux pas récupérer tous les utilisateurs qui suivent un emplacement particulier, ou toutes les photos qu'un emplacement pourrait avoir. J'ai pré-récupéré certains, et d'autres seront fournis par le serveur à la demande. Je veux descendre en restant sur la même vue, par exemple en cliquant sur la page avatar d'un suiveur, je devrais obtenir une petite grille des photos de cet utilisateur, ou sth. Mais je n'ai qu'un currentUser dans le modèle. Cela conduit à la question suivante: pourquoi ai-je même besoin de me lier à un modèle singleton central? Je ne peux pas simplement transformer chaque vue en un sorte de répondeur, c'est-à-dire que la vue distribue encore une fois, mais cette fois la commande au lieu de fournir le modèle fournira directement la vue de l'appel.

Il n'y aura pas de couplage car chaque vue implémentera IResponder. La commande nécessitera seulement un IResponder, qu'il obtiendra de l'événement avec lequel il a été appelé.

Le "modèle" tel que je le vois, jouera un rôle différent. Ce sera plus comme un cache, sorte de dictionnaire global pour le stockage local, qui sera vérifié par la commande avant de faire une requête au serveur. De cette façon, il peut enregistrer certains appels au serveur, bien que, si les données sont très sporadiques, ces mêmes données seront récupérées encore et encore avec d'autres données.(Je peux avoir des données d'utilisateur dans le cache, mais en général j'appelle le serveur pour une collection de données suiveuses, peu importe si j'en ai déjà ou non, pour la cohérence)

idées seront appréciés

Answer 1

Je pense que votre question réelle est la suivante:

cela conduit à la question, pourquoi dois-je besoin même de se lier à un central modèle singleton?

Vous n'avez pas besoin de vous lier à un modèle singleton central. En fait, beaucoup prétendent que cette approche est horrible et entraînera des problèmes de performance. La liaison peut être une opération coûteuse. Par conséquent, la mise en place de toutes les valeurs pouvant être liées peut entraîner des effets d'entraînement dans votre application. Le fait que Cairngorm semble vous pousser dans cette direction est une critique commune pour Cairngorm. Dans la défense de Cairngorm, je ne vois pas pourquoi - dans l'architecture de Cairngorm - vous ne pouvez pas avoir plusieurs «singletons de données globales» si vous voulez. Je m'abstiendrai de régurgiter les arguments contre Singletons en premier lieu.

La plupart des cadres post-Cairngorm peuvent être considérés comme une réponse à Cairngorm et une tentative de faire les choses différemment.

Answer 2

Ce n'est pas vraiment une réponse parce que la question n'est pas vraiment une question. Cependant, si vous voulez regarder 'MVC', vous devriez rester loin loin de Cairngorm car il implémente probablement le pire modèle MVC dans tous les cadres d'application pour Flex. Un des meilleurs exemples (ou pire selon la façon dont vous le regardez) est leur utilisation du modèle singleton qui Theo already blogged about. Vous devez regarder RobotLegs ou Parsley pour une architecture MVC appropriée. Dans mon opinion personnelle de l'architecture, le «modèle» est juste une autre façon de dire «données». C'est juste une classe qui contient des données ou un état pour votre application.