Metodi di utilità nel bean con ambito applicazione

Question

Pensi che sia una buona idea mettere tutti i metodi di utilità ampiamente utilizzati in un bean con ambito applicazione?

Nell'attuale implementazione dell'applicazione su cui sto lavorando, tutti i metodi di utilità (manipolazione con stringhe, cookie, controllo url, controllo della pagina corrente in cui l'utente è ecc.) Sono tutti inseriti in un bean con scope a richiesta grande e sono referenziati da ogni pagina xhtml.

Non sono riuscito a trovare alcuna informazione su stackoverflow se l'approccio di mettere i metodi di utilità in un bean con scope applicazione sarebbe una scelta buona o cattiva.

Perché mi sono imbattuto in questa idea è la necessità di riutilizzare quei metodi in un bean di un ambito più ampio di un bean con scope richiesta (come la vista o il bean con scope di sessione). Correggetemi se ho torto ma dovreste iniettare sempre i bean con scope uguali o più ampi, cioè non dovreste iniettare il bean scope scope all'interno di uno scope con scope di vista.

Penso che usare i metodi di utilità dal bean con scope dell'applicazione dovrebbe essere vantaggioso (non ci saranno nuove creazioni di oggetti, un oggetto verrà creato e riutilizzato in tutte le applicazioni), ma comunque vorrei una conferma o qualcuno per dirmi se questo è un approccio sbagliato e perché è sbagliato.

Answer 1

Per quanto riguarda l'ambito del bean, se il bean non ha uno stato (vale a dire che la classe non ha variabili di istanza mutabili), allora può tranquillamente essere applicato all'ambito dell'applicazione. Vedi anche How to choose the right bean scope? Tutto questo indipendentemente dallo scopo del bean (utility o no). Dato che le funzioni di utilità sono stateless per definizione, è consigliabile utilizzare un bean con ambito applicazione. Salva il costo dell'istanziazione su ogni singola richiesta.

Per quanto riguarda i metodi di utilità in un bean gestito, in prospettiva orientata agli oggetti questa è una pratica inadeguata, perché per poterli accedere da EL questi metodi non possono essere static mentre dovrebbero essere. Non è possibile utilizzarli come metodi di utilità reali in altre normali classi Java. Analizzatori di codici statici come Sonar li contrassegneranno tutti con una grande bandiera rossa. Questo è quindi un anti-modello. L'approccio corretto sarebbe quello di continuare ad usare una vera e propria classe di utilità (public final class con private Constructor() con unicamente static metodi) e registrare tutte quelle static metodi come funzioni EL in your.taglib.xml come descritto nel How to create a custom EL function to invoke a static method?

Almeno, questo è ciò che si dovrebbe fare quando si intende avere una libreria riutilizzabile pubblicamente come JSTL fn:xxx(), PrimeFaces p:xxx() o OmniFaces of:xxx(). Se si utilizza OmniFaces, è possibile, invece di creare un file your.taglib.xml, fare riferimento alla classe in <o:importFunctions>. Esporterà automaticamente tutti i metodi public static del tipo specificato in ambito di funzione EL.

<o:importFunctions type="com.example.Utils" var="u" /> 
... 
<x:foo attr="#{u:foo(bean.property)}" /> 

Se non si utilizza OmniFaces, e tutto questo è per uso interno, quindi posso immaginare che diventa faticoso rifare tutto ciò che boilerplate your.taglib.xml registrazione per ogni funzione di utilità molto piccolo che si apre all'improvviso. Riesco a razionalizzare e perdonare l'abuso di un bean con scope dell'applicazione per questi casi di "uso interno solo". Solo quando inizi a esternalizzarlo/modularizzarlo/pubblicizzarlo, dovresti davvero registrarli come funzioni EL e non esporre le pratiche inadeguate in pubblico.