Problemi JSF dovuti allo stato lato server condiviso

1

Sul suo ultimo radar tecnologico, i ragazzi di ThoughtWorks consigliano di evitare JSF perché il tentativo di creare stato su HTTP finisce per "causare un'intera serie di problemi che coinvolgono lo stato condiviso lato server".

Utilizzo JSF 2.x da quasi un paio d'anni, mi piace e non posso dire di aver riscontrato problemi di questo tipo. Ma non ho molta esperienza con esso e molto meno con le alternative, quindi mi piacerebbe capire quali sono "tutta una serie di problemi"?

Le domande su JSF di solito sollevano alcune accese discussioni, quindi penso che valga la pena essere chiari: si tratta di JSF 2.x, ma non del fatto che sia meglio o peggio di X o Y, se sia architettonicamente giusto mettere lo stato in HTTP o qualcosa del genere. Vorrei solo sapere quali sono questi problemi dal momento che il radar non va su specifiche.

    
posta andrepnh 27.02.2014 - 13:45
fonte

1 risposta

1

Sono riuscito a trovare alcuni fatti utili sui problemi nel modello HTTP stateful. L'originale "intera serie di problemi che coinvolgono lo stato lato server condiviso" mi sembra ancora vaga, ma alcuni dei riferimenti che ho raccolto lo coprono in una certa misura (e interpretazione).

Prima vengono i problemi di prestazioni, uno dei reclami più comuni. JSF deve creare, gestire e inviare lo stato di visualizzazione avanti e indietro, tra il client e il server, e questo è molto costoso. Questo costo può essere minimizzato in qualche misura da:

  • Uso di un'implementazione diversa. Ho trovato un post sul blog del 2012 che sottolinea che 2.1. 7 MyFaces richiede meno risorse rispetto alla controparte di Mojarra. Tieni presente che, come sempre, i problemi di prestazioni possono cambiare nelle versioni future.
  • Disattiva il salvataggio dello stato, che dovrebbe effettivamente risolvere tutti questi problemi, ma le prestazioni non sono ancora ottimali. Questa risposta mostra che JSF 2.2 con stato disabilitato è ancora più lento del semplice servlet. Si noti che un utente si chiede se si tratti di un confronto valido o meno.

In secondo luogo, offrire un'esperienza RIA può essere più difficile quando lo stato non appartiene al cliente. Anche questo si riduce alle prestazioni, ma sembra essere più di questo. Per simulare un'esperienza simile a un desktop in un'applicazione HTTP stateful, gli sviluppatori finiscono per gestire direttamente la complessità dello stato di visualizzazione. Credo che l'implementazione di un qualche tipo di flusso dell'interfaccia utente sia un buon modo per vederlo. Funziona, ma è abbastanza disordinato. JSF 2.2 fornisce l'ambito del flusso per semplificare il lavoro dello sviluppatore, ma l'ho trovato ancora un po 'approssimativo ai bordi. Questo post fornisce un semplice esempio di questo tipo di problema .

Infine, fare affidamento sulla sessione per mantenere lo stato di visualizzazione rende più difficile il compito di raggruppare l'applicazione in quanto è necessario condividere quella sessione tra le istanze. I server delle applicazioni forniscono meccanismi per farlo, ma finirai per utilizzare più risorse. Inoltre, alcuni fornitori PaaS addebiteranno per la replica della sessione. Usarlo solo a causa di JSF non sembra una buona idea.

    
risposta data 25.04.2014 - 00:43
fonte

Leggi altre domande sui tag