Richieste Ajax, tramite MVC Framework (ad esempio ColdBox) o no?

Question

Invii le richieste Ajax attraverso il framework MVC preferito o direttamente al CFC?

Mi sto inclinando a bypassare l'MVC, poiché non ho bisogno di 'View' dalla richiesta ajax.

Quali sono i pro del routing delle chiamate ajax attraverso il framework MVC, come Coldbox?

aggiornamento: trova questa pagina http://ortus.svnrepository.com/ coldbox / trac.cgi / wiki / cbAjaxHints ma sto ancora provando a pensare ai vantaggi che porta alla complessità che introduce ...

Answer 1

Henry, faccio le mie richieste Ajax per proxy oggetti del mio modello. In genere, sono al di fuori di un "quadro" quando lo faccio. Detto questo, potrebbe essere (molto) necessario utilizzare il tuo framework, ad esempio lavorando all'interno di un modello di sicurezza prestabilito.

Answer 2

Non riesco davvero a vedere alcun vantaggio derivante dall'esclusione del framework MVC: in combinazione, questi tre elementi sono la tua applicazione.

I tuoi elementi ajax fanno davvero parte della vista. Come dice Luca, la vista produce i risultati del modello e del controller.

Guardalo in questo modo: se creassi un'interfaccia web compatibile con iPhone (ovvero una nuova vista), ignoreresti il ??modello e il controller?

Answer 3

Luis Majano, creatore di ColdBox detto :

  

Queste sono le due scuole di Ajax   interazione henry.

     

Preferisco l'approccio proxy perché   aggiunge quanto segue:

     

  
1. Debug
  
2. Traccia nel debugger
  
3. Punti di intercettazione AOP
  
4. Sicurezza
  
5. Impostazione della disponibilità
  
6. Il proxy inoltra al modello di eventi, quindi posso utilizzare l'intercettazione locale   punti, AOP locale, plugin, ecc.
  

     

In altre parole, può essere altamente   chiamata monitorata anziché semplice   servizio di chiamata cfc, che è ancora possibile   fare.

     

Io, per esempio, amo avere la mia esecuzione   profiler in esecuzione (parte della coldbox   debugger), quindi posso vedere quando Ajax   le richieste arrivano e quando arrivano   su. Posso vedere i dati richiesti e   i dati restituiti. Non devo   cerca nei file di registro o prova a immaginare   risultati o problemi. Aiuta davvero   nel debug.

     

Tuttavia, sarebbe uno sviluppatore   scelta in che modo decidi di andare.   La mia preferenza personale è sempre   usa il mio proxy per la delega degli eventi   perché mi dà molto di più   flessibilità, debug e tranquillità di   mente.

Answer 4

Lo scopo di " view " nei framework MVC è mostrare i dati dopo il "modello" e "controller" l'ho generato. Se non hai bisogno di " view " ;, allora qual è lo scopo di utilizzare un tale modello di progettazione?

Answer 5

Sono d'accordo con Luca. Inoltre, ignora qualsiasi tipo di logica di sanificazione e filtro presente nello stack MC. In pratica nega qualsiasi tipo di elaborazione delle query che potresti avere o meno.

Answer 6

Sì, non aggirerei il tuo framework, capire cosa ti sta causando dolore e dare la caccia ai pezzi offensivi, aggiungere la logica per escludere componenti comuni come intestazioni o piè di pagina e cercare metodi che iniettano spazi bianchi che, mentre bene per html è fastidioso o assolutamente problematico quando analizza json.

Aggiunta di output = " false " specialmente nel tuo application.cfc ed i suoi metodi sarebbero la prima cosa che ho ripulito.

Sono fermamente convinto di non accedere MAI direttamente ai CFC direttamente, trovo che crei problemi a lungo termine quando un importante refattore potrebbe voler consolidare o eliminare componenti, gli accessi diretti potenzialmente rendono questo più difficile di quanto dovrebbe essere, soprattutto se un terze parti stanno colpendo il tuo Ajax da un altro dominio (ad es. flash remoting).

+1 alla risposta di Steve.