ExtJS 4.1 - Store.add() (następuje synchronizacja) vs Model.save()

Question

pierwszy: uświadamiam sobie to pytanie zostało zadane tutaj: in ExtJS, is it better to call Model.save() or Store.Sync()? - jednak pragnę zbadać to dalej, w szczególności dotyczące minimalizacji i XHR niepotrzebne obciążenie zarówno klienta, jak i serwera. Nie uważam, aby któryś z tych punktów był poruszany w połączonym pytaniu.

Mam dość dużą aplikację przeznaczoną do zarządzania zasobami przedsiębiorstwa, składającą się z wielu modeli, widoków i kontrolerów. Obsługuję wszystkie odpowiedzi z mojego serwera, ustanawiając odbiornik zdarzeń Ext.Ajax requestComplete i requestException. Podjęłam to podejście, zamiast pisać zduplikowane procedury obsługi zdarzeń na zdarzeniu każdego modelu proxy o numerze afterRequest. Dzięki temu mam wszystkie back-end (za pomocą Zend Framework) kontrolerów odpowiadających trzema parametrami: success, message i data.

Po pomyślnym żądaniu (tj. HTTP 200), metoda uruchomiona dla requestComplete będzie sprawdzać odpowiedź JSON dla wyżej wymienionych parametrów. Jeśli success jest false, oczekuje się, że pojawi się komunikat o błędzie zawarty w message, który zostanie wyświetlony użytkownikowi (np. "Wystąpił problem podczas zapisywania tego produktu." Niepoprawna nazwa produktu "). Jeśli sukces jest prawdą, działanie jest podejmowane w zależności od typu żądania, tj. Utwórz, Odczyt, Aktualizuj lub Zniszcz. Po udanym create nowy rekord zostanie dodany do odpowiedniej składnicy danych, po usunięciu rekord zostanie zniszczony i tak dalej.

Zdecydowałem się na takie podejście, zamiast dodawać zapisy do sklepu i wywoływać metodę sklepu w celu zminimalizowania podróży XHR i innych podróży w obie strony. Moim aktualnym sposobem zapisywania/aktualizowania danych jest wysłanie żądania do zaplecza i reakcja na wynik na interfejsie Ext. Robię to, wypełniając model danymi i wywołując model.save() dla żądań create/update lub model.destroy() w celu usunięcia danych.

Znalazłem, że podczas dodawania/aktualizowania/usuwania rekordów ze sklepu, a następnie wywoływania store.sync(), musiałbym reagować na odpowiedź serwera w sposób, który wydawał mi się niezręczny. Weźmy na przykład usunięcie rekordu:

1. Najpierw wyjmij płytę ze sklepu poprzez store.remove()
2. Invoke store.sync() jak mam sklepu autoSync zestaw do false.
3. Spowoduje to wywołanie żądania niszczenia AJAX z modelu proxy sklepu.
4. Oto, gdzie robi się dziwne .... jeśli wystąpi błąd na serwerze podczas opuszczania wiersza z bazy danych, odpowiedź zwróci success: false, jednak rekord zostanie już usunięty ze sklepu danych ExtJS.
5. W tym miejscu mogę albo zadzwonić pod numer store.sync(), store.load() (obie wymagające podróży w obie strony), albo pobrać rekord z żądania i dodać go z powrotem do sklepu, a następnie commitChanges(), aby uniknąć wywoływania dodatkowej synchronizacji/obciążenia i tym samym uniknąć niepotrzebna podróż w obie strony.

To samo dotyczy dodawania rekordów, jeśli serwer nie gdzieś podczas dodawania danych do bazy danych, rekord jest jeszcze w sklepie ExtJS i muszą być usuwane ręcznie, aby uniknąć podróży w obie strony z store.sync() lub store.load().

Aby uniknąć tego problemu, jak już wcześniej wyjaśniłem, należy utworzyć instancję jednego z moich obiektów modelu (np.model produktu), zapełnić go danymi i zadzwonić pod numer myModel.save(). To z kolei wywołuje proxy w postaci create lub update w zależności od identyfikatora modelu i odpala odpowiednie żądanie AJAX. W przypadku niepowodzenia back-end, sklep front-end pozostaje niezmieniony. W przypadku pomyślnych wniosków (czytaj: success: true, a nie HTTP 200), ręcznie dodajemy rekord do sklepu i wywołuję store.commitChanges(true), skutecznie synchronizując sklep z bazą danych bez dodatkowej podróży w obie strony i unikając niepotrzebnego narzutu. W przypadku wszystkich żądań serwer odpowie na nowe/zmodyfikowane dane, a także parametr sukcesu i warunkowo komunikat wyświetlany na kliencie.

Czy brakuje mi tutaj czegoś, czy też to podejście jest dobrym sposobem na zminimalizowanie narzutu XHR i serwera/klienta? Z przyjemnością dostarczę przykładowy kod, o który należy poprosić, jednak uważam, że jest to raczej ogólna koncepcja z podstawowym kodem.

Answer 1

Myślę, że elokwentnie argumentowałeś swoją pozycję. Nie widzę niczego złego w pozycji, którą podjąłeś. Jedynym moim zarzutem jest wskazanie, że ustawienie autoSync w sklepie, który wspiera edytowalną siatkę, jest znacznie mniej szczegółowym sposobem wykonania zadania, choć z mniejszą kontrolą.

Aby dodać, narzut, na który zwracasz uwagę, jest zwykle spowodowany nieoczekiwanymi lub wywoływanymi przypadkami, które mogą wymagać specjalnej obsługi lub dodatkowego odświeżenia danych. Możesz dodać detektory dla tych konkretnych przypadków i pozostawić resztę działającą z domyślnymi wartościami domyślnymi.