Demandes Ajax, via MVC Framework (par exemple, ColdBox) ou non?
-
05-07-2019 - |
Question
Envoyez-vous les requêtes ajax via le framework MVC de votre choix ou directement vers le CFC?
Je suis plutôt enclin à contourner le MVC, car je n'ai pas besoin de "Voir" depuis la requête ajax.
Quels sont les professionnels du routage des appels ajax via le framework MVC, comme Coldbox?
mise à jour: trouvé cette page http://ortus.svnrepository.com/ coldbox / trac.cgi / wiki / cbAjaxHints , mais j’essaie toujours de comprendre les avantages que cela apporte par rapport à la complexité qu’il introduit ...
La solution
Henry, je soumets mes requêtes Ajax à des objets proxy de mon modèle. En règle générale, je suis en dehors d'un "cadre" lorsque je le fais. Cela dit, il peut être (très) nécessaire d’utiliser votre infrastructure, par exemple pour travailler dans un modèle de sécurité défini.
Autres conseils
Je ne vois vraiment aucun avantage à contourner le cadre MVC. Ces trois éléments sont en combinaison votre application .
Vos éléments ajax font vraiment partie de la vue. Comme Luca le dit, la vue affiche les résultats du modèle et du contrôleur.
Si vous avez créé une interface Web conviviale pour l'iPhone (c'est-à-dire une nouvelle vue), pouvez-vous contourner le modèle et le contrôleur?
Luis Majano, créateur de ColdBox a déclaré :
Ce sont les deux écoles d'ajax interaction henry.
Je préfère l'approche par procuration parce qu'elle ajoute ce qui suit:
- Débogage
- Suivi dans le débogueur
- points d'interception AOP
- Sécurité
- Définition de la disponibilité
- Le proxy relèvera du modèle d'événement pour que je puisse utiliser l'interception locale. points, AOP locales, plugins, etc.
En d'autres termes, il peut être très appel surveillé au lieu d'un simple appel de service cfc, que vous pouvez toujours faire.
Moi, j'adore avoir mon exécution profileur en cours d'exécution (partie de la coldbox débogueur), afin que je puisse voir quand ajax les demandes arrivent et quand elles arrivent en dehors. Je peux voir les données demandées et les données renvoyées. Je n'ai pas à regardez dans les fichiers journaux ou essayez d'imaginer résultats ou problèmes. Ça aide vraiment dans le débogage.
Cependant, ce serait un développeur choix dans quelle direction vous décidez d'aller. Ma préférence personnelle est de toujours utiliser mon proxy pour la délégation d'événements parce que ça me donne beaucoup plus la flexibilité, le débogage et la paix de esprit.
Objet de la "vue" dans les frameworks MVC, il faut montrer les données après le "modèle". et " contrôleur " l'ont généré. Si vous n'avez pas besoin de la "vue", quel est l'intérêt d'utiliser un tel motif de conception?
Je suis d'accord avec Luca. Elle contourne également tout type de logique de désinfection et de filtrage que vous avez dans votre pile MC. Cela supprime fondamentalement tout type de traitement de requête que vous pouvez avoir ou non en place.
Oui, je ne contournerais pas votre cadre, découvririez ce qui vous causait du chagrin et traqueriez les éléments incriminés, en ajoutant une logique pour exclure les composants courants tels que les en-têtes ou les pieds de page, et en recherchant des méthodes permettant d'injecter des espaces qui, bien qu'en HTML problématique gênante ou très problématique lors de l’analyse de JSON.
Ajout de la sortie = " faux " en particulier dans votre application.cfc et ses méthodes seraient la première chose que j'ai nettoyée.
Je suis un fervent partisan de ne JAMAIS accéder directement aux CFC directement. Je trouve que cela crée des problèmes à long terme lorsqu'un refactor majeur peut vouloir consolider ou éliminer des composants. Les accès directs rendent potentiellement la tâche plus difficile qu'elle ne le devrait, en particulier si une un tiers frappe votre ajax depuis un autre domaine (par exemple, flash remoting).
+1 à la réponse de Steve.