Bean con ambito richiesta e inizializzazione del modello di dati?

Question

AGGIORNAMENTO II:OK, sono riuscito a restringere un po' il campo.

Ho una pagina con un datatable con funzionalità di ordinamento e filtro, entrambe svolte nel DB.In altre parole, non utilizzo la funzionalità incorporata del rich:datatable che utilizzo, ma piuttosto lascio che sia il DB a fare il lavoro.

lavoro con con ambito richiesta fagioli.Gli unici bean con ambito sessione contengono l'ordinamento e il filtraggio della mia interfaccia.

Il filtraggio per ciascuna colonna è legato a determinati campi del bean di sessione.In quanto tale, viene effettivamente aggiornato durante la fase di aggiornamento dei valori del modello.

L'ordinamento ha richiesto una certa logica da parte mia, quindi invoco un determinato metodo per impostare i valori corretti sul bean di sessione.Questa operazione viene eseguita durante la fase di richiamo dell'applicazione.

Pertanto, eventuali modifiche vengono apportate durante la fase di risposta al rendering, in cui la pagina viene effettivamente visualizzata.

Il problema è che il datatable JSF e il datascroller nella mia pagina chiamano il file backingBean.getDataModel() che recuperano i dati dal DB e dal file dataModel.getRowCount() (che ho implementato per invocare un metodo che esegue una query separata) Anche durante Applica i valori della richiesta fase.Queste due query hanno luogo anche durante la fase di rendering della risposta, che è l'unica fase in cui le modifiche sono tutte a posto e la query verrà eseguita normalmente.

Ciò significa che per mostrare una pagina dopo aver eseguito il filtraggio o l'ordinamento, viene effettuato il doppio del numero di query.

Desidero eseguire l'ordinamento e il filtraggio eseguendo solo le query richieste e non di più.

Eventuali suggerimenti?

Answer 1

La chiamata getter durante la fase di applicazione dei valori di richiesta è obbligatoria perché JSF ha bisogno di sapere quali valori di input sono stati inizialmente mostrati in modo da poter eventualmente eseguire qualsiasi convalida e/o chiamare qualsiasi valuechangelisteners nella fase successiva, ove applicabile.È inoltre obbligatorio scoprire quale pulsante/link è stato premuto/cliccato in una qualsiasi delle righe in modo da sapere quale azione del bean chiamare nella fase di azione di invocazione.

Ma se non hai campi di input che devono essere convalidati/controllati per la modifica del valore né pulsanti/link in nessuna delle righe, allora posso immaginare che la query durante la fase di applicazione dei valori di richiesta sia ai tuoi occhi completamente superflua.

Sfortunatamente, non puoi disabilitarlo completamente.Tecnicamente, l'unica soluzione è inserire il bean di dati nell'ambito della sessione ed eseguire la costosa query SQL (e l'aggiornamento del modello di dati) solo nel costruttore del bean e nel metodo di azione del bean, in modo che venga invocato solo durante l'esecuzione del bean costruzione (per la prima visualizzazione) e durante il metodo di azione del bean (durante un nuovo ordinamento/filtro/qualunque richiesta).Lo svantaggio è tuttavia che eventuali modifiche nel datamodel si riflettono in tutte le finestre/schede che l'Enduser ha aperto nella stessa sessione, il che potrebbe causare "WTF?" Esperienze per l'Enduser.

Ora, Tomahawk è stato il primo ad avere una bella soluzione alternativa a questo problema nel sapore di preserveDataModel attributo per il <t:dataTable>, che sostanzialmente inserisce il modello di dati nell'albero dei componenti specifico della richiesta (che a sua volta è già archiviato nell'ambito della sessione o in un campo di input nascosto sul lato client, a seconda di come hai configurato la posizione di archiviazione dello stato di visualizzazione in faces- configurazione).RichFaces non ha una soluzione diretta del genere, ma il file <a4j:keepAlive> fa sostanzialmente la stessa cosa.Interesserebbe solo il bean "intero", quindi se il tuo bean di dati contiene più del solo modello di dati, potresti prendere in considerazione il refactoring.È necessario tenere presente di progettare il bean come se fosse un bean con ambito di sessione.

Se il modello di dati diventa grande, posso immaginare che ciò abbia un impatto sulla memoria del server, ma ciò non dovrebbe danneggiare più di tanto se memorizzi solo il visualizzabile parte del datamodel in memoria (e quindi non il intero datamodel, comprese tutte le altre pagine).Verifica se supera il costo di eseguire doppie query SQL durante una singola richiesta HTTP.

Spero che questo ti aiuti.