ExtJS 4.1 - Store.add() (seguito da sync) vs Model.save()

Question

PRIMO: Mi rendo conto che questa domanda è stato chiesto qui: in ExtJS, is it better to call Model.save() or Store.Sync()? - tuttavia vorrei esaminare ulteriormente questo aspetto, in particolare per quanto riguarda minimizzando XHR e di sovraccarico non necessario su client e server. Non ritengo che uno di questi punti sia stato affrontato nella domanda collegata.

Ho un'applicazione piuttosto grande progettata per la gestione delle risorse aziendali, composta da molti modelli, viste e controller. Gestisco tutte le risposte dal mio server stabilendo un ascoltatore su eventi Ext.Ajax requestComplete e requestException. Ho seguito questo approccio piuttosto che scrivere gestori di eventi duplicati sull'evento proxy di ogni modello afterRequest. Ciò mi consente di avere tutti i miei controller di back-end (usando il framework Zend) che rispondono con tre parametri: success, message e data.

Dopo una richiesta riuscita (ad esempio, HTTP 200), il metodo eseguito per requestComplete ispezionerà la risposta JSON per i parametri sopra menzionati. Se success è false, è previsto che venga visualizzato un messaggio di errore in message, che viene quindi visualizzato all'utente (ad esempio "Si è verificato un problema durante il salvataggio del prodotto. Nome prodotto non valido"). Se il successo è vero, l'azione viene eseguita in base al tipo di richiesta, ovvero Crea, Leggi, Aggiorna o Distruggi. Dopo il successo di create, il nuovo record viene aggiunto all'archivio dati appropriato, dopo che il record è stato eliminato e così via.

Ho scelto di adottare questo approccio piuttosto che aggiungere record a un negozio e chiamare il metodo sync del negozio al fine di ridurre al minimo i viaggi XHR e di altro tipo. Il mio attuale mezzo per salvare/aggiornare i dati è inviare la richiesta al back-end e reagire al risultato sul front-end di Ext. Faccio questo popolando un modello con dati e chiamando model.save() per le richieste di creazione/aggiornamento, o model.destroy() per rimuovere i dati.

Ho scoperto che durante l'aggiunta/l'aggiornamento/la rimozione di record da un negozio, quindi chiamando store.sync(), avrei dovuto reagire alla risposta del server in un modo che sembrava imbarazzante. Prendete per esempio, l'eliminazione di un record:

1. In primo luogo, rimuovere il record dal negozio tramite store.remove()
2. Invoke store.sync() come ho autoSync set del negozio per false.
3. Attiva la richiesta di eliminazione AJAX dal proxy del modello del negozio.
4. Ecco dove diventa strano .... se si verifica un errore sul server mentre si rilascia la riga dal database, la risposta restituirà success: false, tuttavia il record sarà già stato rimosso dall'archivio dati ExtJS.
5. A questo punto, posso chiamare store.sync(), store.load() (entrambi richiedono un viaggio di andata e ritorno) o ottenere il record dalla richiesta e aggiungerlo di nuovo allo store seguito da un commitChanges() per evitare di chiamare un ulteriore sincronizzazione/carico e quindi evitare un viaggio non necessario e non necessario

Lo stesso vale per l'aggiunta di record, se il server non riesce da qualche parte, mentre l'aggiunta di dati al database, il record è ancora in negozio ExtJS e deve essere rimosso manualmente per evitare un giro con store.sync() o store.load().

Per evitare questo problema, come ho spiegato in precedenza, istanzio uno dei miei oggetti modello (ad es.un modello di prodotto), compilare i dati e chiamare myModel.save(). Questo, a sua volta, richiama il proxy create o update a seconda dell'ID del modello e apre la richiesta AJAX appropriata. Nel caso in cui il back-end non riesca, l'archivio front-end rimane invariato. In caso di richieste riuscite (leggi: success: true, non HTTP 200), aggiungo manualmente il record allo store e invoco store.commitChanges(true), sincronizzando efficacemente l'archivio con il database senza un ulteriore round trip ed evitando inutili spese generali. Per tutte le richieste, il server risponderà con i dati nuovi/modificati e un parametro di successo, e condizionalmente un messaggio da visualizzare sul client.

Mi manca qualcosa qui o questo approccio è un buon modo per ridurre al minimo XHR e sovraccarico server/client? Sono felice di fornire un codice di esempio che dovrebbe essere richiesto, tuttavia ritengo che questo sia un concetto piuttosto generale con codice fondamentale.

Answer 1

Penso che tu abbia eloquentemente discusso la tua posizione. Non vedo nulla di sbagliato nella posizione che hai assunto. Il mio unico rimprovero è quello di sottolineare che l'impostazione di autoSync su un negozio che supporta la griglia modificabile è un modo molto meno prolisso di eseguire l'attività, anche se con meno controllo.

Per aggiungere, l'overhead che si indica è in genere a causa dell'imprevisto o chiamerei casi limite che potrebbero richiedere una gestione speciale o un aggiornamento aggiuntivo dei dati. È possibile aggiungere listener per quei casi specifici e lasciare il resto funzionante con valori predefiniti concisi.