Demandes Ajax, via MVC Framework (par exemple, ColdBox) ou non?

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 ...

Answer 1

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.

Answer 2

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?

Answer 3

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:

     

  
1. Débogage
  
2. Suivi dans le débogueur
  
3. points d'interception AOP
  
4. Sécurité
  
5. Définition de la disponibilité
  
6. 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.

Answer 4

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?

Answer 5

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.

Answer 6

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.