Gestione delle risorse collegate nell'interfaccia utente

3

Ho un'entità Hotel che può avere molti address e molti image oggetti, ad esempio, sono uno2many correlati con l'hotel.

La domanda sorge durante il recupero e il salvataggio della risorsa collegata.

Recupero

  1. Carico la risorsa che è Hotel qui che ha la matrice ids dell'indirizzo e immagine, questi indirizzi contengono gli identificativi univoci per ciascuna risorsa correlata, dopo che l'hotel è stato recuperato la richiesta successiva viene fatta per recuperare indirizzo e immagini una dopo l'altra o in parallelo (il parallelo potrebbe essere migliore perché non sono correlate). Lo svantaggio è che ci sono tre richieste di rete (una per l'hotel e poi gli indirizzi e le immagini) e ha lo svantaggio di mostrare le informazioni parziali come tutti gli indirizzi non completamente recuperati nel caso in cui il server sia inattivo.
  2. Quando viene richiesta la risorsa hotel, l'applicazione sul server fa tutto il lavoro e, con l'aiuto del database, tutte le informazioni vengono inviate in un'unica soluzione, probabilmente impiegando più tempo. Ora, in questo caso la risorsa ha una matrice di indirizzi reali e oggetti immagine.

Salvataggio

  1. In caso di nuova risorsa tutte le informazioni vengono passate al server in una sola volta, vale a dire la risorsa con l'array di indirizzi e collegamenti di miniature. In questo caso, le risorse collegate vengono salvate per prime, cioè l'indirizzo viene salvato per primo, quindi il suo id è collegato alla risorsa e quindi la risorsa viene salvata. Se l'indirizzo non riesce a salvare, eseguiamo il rollback dell'intera azione e lo consideriamo fallito e chiediamo al cliente di riprovare.
  2. Per l'aggiornamento devo riflettere ancora, magari progettare l'interfaccia utente in modo tale che sia possibile aggiornare una sola risorsa collegata alla volta.

Mi piacerebbe sapere se esiste un approccio migliore o quale sia il mio approccio migliore e perché?

    
posta CodeYogi 08.07.2017 - 05:45
fonte

2 risposte

6

È probabile che il tuo livello di persistenza si unisca più velocemente di quanto fai con più feti e ti unisci al livello dell'applicazione.

Dovresti capire il tuo comportamento predefinito che gestisce il 60% di tutte le esigenze e quindi aggiungere un parametro facoltativo per gestire il restante 40%. Se hai costantemente bisogno di tutte le immagini e gli indirizzi con la risorsa, il tuo predefinito è di restituirli tutti con una singola richiesta a quella risorsa. Quindi definire un comportamento di selezione in cui specificare quali dati si desidera recuperare per i casi rimanenti.

Credo che il # 2 sarebbe il migliore dei due dato che il n. 1 introduce un'indezione indiretta inutile.

Per quanto riguarda il salvataggio, dipende dal contesto delle esigenze dell'applicazione. La risorsa richiede almeno 1 indirizzo e immagine? Queste risorse sono facoltative? Puoi aggiungere più immagini / indirizzo più tardi?

In definitiva, il server dovrebbe semplificare la vita del cliente. Sarebbe più facile avere la possibilità di creare l'intera risorsa in un colpo solo e aggiungere direttamente nuove risorse.

    
risposta data 08.07.2017 - 06:20
fonte
0

Vorrei andare con l'approccio che si adatta meglio man mano che il database cresce. Prendi la chiamata extra per sessione e risparmia sul colpo di performance iniziale e sull'uso della memoria sul lato client.

Non sono sicuro che abbia senso, non capisco completamente la domanda.

    
risposta data 17.07.2017 - 07:21
fonte