Perché aggiornare il modello client prima del modello sever?

3

Nelle esercitazioni che ho visto, quando i dati cambiano sul client (forse un TODO viene aggiunto all'elenco TODO) il modello lato client (e spesso l'interfaccia utente) viene aggiornato per primo, quindi il server viene chiamato per mantenere tale modifica. Questo mi imbarazza perché c'è il potenziale di errore e fallimento (nel qual caso dovresti notificare il client e annullare la modifica sul modello di dati / UI).

È meglio aggiornare prima il server, quindi il modello / l'interfaccia utente del client o viceversa?

    
posta user1775718 20.09.2015 - 02:25
fonte

1 risposta

4

In genere è più semplice aggiornare prima il server e poi aggiornare l'interfaccia utente quando il server risponde con successo.

Ciò consente di evitare la gestione dei casi in cui è stata aggiornata l'interfaccia utente, ma l'aggiornamento del server ha esito negativo.

Ma rende anche gli utenti in attesa che la richiesta del server venga completata prima di visualizzare i risultati nell'interfaccia utente.

Il modo migliore dipende dalle tue priorità e dalla tua applicazione. Per alcune applicazioni è anche facile (solo un po 'più di lavoro) per gestire casi in cui gli aggiornamenti del server falliscono aggiornando nuovamente l'interfaccia utente. Per alcune applicazioni questo diventa piuttosto complesso e può portare gli utenti a prendere decisioni sbagliate con conseguenze frustranti o addirittura pericolose.

Ad esempio, mostra a un medico sul suo iPad che è stato ordinato un farmaco prima che il server lo confermi, e potresti aver danneggiato il paziente, se il farmaco non fosse stato effettivamente ordinato, a causa di una breve interruzione della rete o altro problema, il medico può posare l'iPad e andarsene pensando che il lavoro sia finito.

In questo caso, uno stato di ritardo o di attesa sembra essere in ordine nell'interfaccia utente. Sebbene lo stato di attesa sia più gradevole, a volte ad es. per ragioni di sicurezza, un ritardo e una conferma formale sono migliori. Questa è una questione di progettazione dell'esperienza utente.

Il trading di titoli, un'altra area dalla mia esperienza, è quella in cui non dovresti dire a un utente che qualcosa è fatto quando non lo è. I trader sono abituati a guardare gli ui complessi con gli indicatori di stato e per lo più odiano il ritardo. Tuttavia, in questo caso, gli indicatori di stato e l'interfaccia utente dinamica richiesti possono aggiungere molto più spazio rispetto alla semplice attesa di conferma da parte del server.

Nel complesso, la risposta non è tecnica. In questo caso è davvero un'esperienza utente che dovrebbe guidare, insieme al budget per lo sviluppo.

    
risposta data 20.09.2015 - 10:04
fonte

Leggi altre domande sui tag