ExtJS 4.1 - Store.add() (gefolgt von sync) vs Model.save()

Question

FIRST: Ich weiß, diese Frage hier gefragt wurde: in ExtJS, is it better to call Model.save() or Store.Sync()? - aber ich wünschte, dies weiter zu untersuchen, insbesondere in Bezug auf die Minimierung XHR ist und unnötiger Overhead auf dem Client und dem Server. Ich glaube nicht, dass einer dieser Punkte in der verknüpften Frage angesprochen wurde.

Ich habe eine etwas große Anwendung für Enterprise Resource Management, bestehend aus vielen Modellen, Ansichten und Controllern. Ich behandle alle Antworten von meinem Server, indem ich einen Listener für die Ereignisse Ext.Ajax requestComplete und requestException erstelle. Ich habe diesen Ansatz gewählt, anstatt doppelte Ereignishandler für jedes Proxy-Ereignis des Modells afterRequest zu schreiben. Dies ermöglicht mir, dass alle meine Backend-Controller (mit dem Zend Framework) mit drei Parametern antworten: success, message und data.

Nach einer erfolgreichen Anforderung (d. H. HTTP 200) untersucht die für requestComplete ausgeführte Methode die JSON-Antwort auf die oben genannten Parameter. Wenn successfalse ist, wird erwartet, dass eine Fehlermeldung in message enthalten ist, die dann dem Benutzer angezeigt wird (z. B. "Beim Speichern dieses Produkts ist ein Problem aufgetreten. Ungültiger Produktname"). Wenn der Erfolg wahr ist, wird abhängig von der Art der Anfrage, d. H. Erstellen, Lesen, Aktualisieren oder Zerstören, eine Aktion ausgeführt. Nach einem erfolgreichen create wird der neue Datensatz dem entsprechenden Datenspeicher hinzugefügt, nach dem Löschen wird der Datensatz zerstört und so weiter.

Ich wählte diesen Ansatz, anstatt Datensätze zu einem Geschäft hinzuzufügen und die sync-Methode des Geschäfts aufzurufen, um XHRs und andere Rundreisen zu minimieren. Mein aktuelles Mittel zum Speichern/Aktualisieren von Daten besteht darin, die Anfrage an das Backend zu senden und auf das Ergebnis am Ext-Frontend zu reagieren. Dazu befüllen Sie ein Modell mit Daten und rufen model.save() für Erstellungs-/Aktualisierungsanforderungen oder model.destroy() auf, um die Daten zu entfernen.

Ich fand, dass beim Hinzufügen/Aktualisieren/Entfernen von Datensätzen aus einem Geschäft, dann store.sync() aufrufen, ich auf die Antwort des Servers in einer Weise reagieren müsste, die sich peinlich. Nehmen Sie zum Beispiel das Löschen eines Datensatzes:

1. Entfernen Sie zuerst den Datensatz aus dem Speicher über store.remove()
2. Invoke store.sync() als ich autoSync Set false der Speicher.
3. Dadurch wird die AJAX-Zerstörungsanforderung vom Modell-Proxy des Geschäfts ausgelöst.
4. Hier wird es komisch .... Wenn ein Fehler auf dem Server auftritt, während die Zeile aus der Datenbank gelöscht wird, gibt die Antwort success: false zurück, der Datensatz wurde jedoch bereits aus dem ExtJS Data Store entfernt.
5. An dieser Stelle kann ich entweder nennen store.sync(), store.load() (beide eine Rundfahrt erforderlich) oder den Datensatz aus der Anfrage bekommen und es zurück in den durch ein commitChanges() eine zusätzliche Synchronisations-/Lade aufrufe und damit zu vermeiden, gefolgt Speicher hinzufügen zu vermeiden eine unnötige Rundreise.

Das gleiche gilt für das Hinzufügen von Datensätzen, wenn der Server irgendwo ausfällt, während Daten in die Datenbank hinzugefügt, der Datensatz noch in der ExtJS Speicher und muss manuell eine Rundfahrt mit store.sync() oder store.load() zu vermeiden, entfernt werden.

Um dieses ganze Problem zu vermeiden, wie ich zuvor erklärt habe, instanziiere ich eines meiner Modellobjekte (z.ein Produktmodell), füllen Sie sie mit Daten und rufen Sie myModel.save(). Dies wiederum ruft die create oder update des Proxys in Abhängigkeit von der ID des Modells auf und löst die entsprechende AJAX-Anforderung aus. Wenn das Back-End fehlschlägt, ist der Front-End-Speicher unverändert. Bei erfolgreichen Anforderungen (lesen Sie: success: true, nicht HTTP 200), ich manuell den Datensatz zum Speicher hinzufügen und store.commitChanges(true) aufrufen, effektiv den Speicher mit der Datenbank ohne einen zusätzlichen Umlauf und unnötigen Overhead zu synchronisieren. Bei allen Anfragen antwortet der Server mit den neuen/geänderten Daten sowie einem Erfolgsparameter und bedingt mit einer Nachricht, die auf dem Client angezeigt werden soll.

Fehle ich etwas hier, oder ist dieser Ansatz eine gute Möglichkeit, XHRs und Server/Client-Overhead zu minimieren? Ich bin froh, Beispielcode zur Verfügung stellen zu können, sollte dies verlangt werden, jedoch denke ich, dass dies ein ziemlich allgemeines Konzept mit fundamentalem Code ist.

Answer 1

Ich denke, Sie haben Ihre Position eloquent argumentiert. Ich sehe nichts falsch mit der Position, die Sie eingenommen haben. Mein einziger Vorwurf ist, darauf hinzuweisen, dass die autoSync-Einstellung in einem Speicher, der editierbares Grid unterstützt, eine weit weniger ausführliche Art ist, die Aufgabe zu erfüllen, wenn auch mit weniger Kontrolle.

Um hinzuzufügen, ist der Aufwand, auf den Sie hinweisen, in der Regel auf das Unerwartete zurückzuführen, oder ich würde Kantenfälle nennen, die eine spezielle Behandlung oder eine zusätzliche Aktualisierung der Daten erfordern. Sie könnten Listener für diese speziellen Fälle hinzufügen und den Rest mit knappen Standardwerten arbeiten lassen.