Le annotazioni @Named o @ManagedBean vengono in genere utilizzate per consentire al contenitore bean (CDI/JSF) di creare un'istanza di un bean su richiesta quando viene fatto riferimento al linguaggio delle espressioni in JSF.
Per un bean @Entity, spesso non ha molto senso ottenere una nuova istanza arbitraria. Un @Entity è fortemente connesso a un'identità persistente. Tale entità è quindi richiesta dallo Entity Manager e non da un contenitore di bean.
Lo schema tipico consiste nell'avere un bean di supporto (sottile) chiamato come chiamata a un servizio (che a sua volta è tipicamente @Stateless in Java EE). Il servizio restituisce quindi le entità.
In alcuni sistemi molto banali, le persone a volte rendono il servizio denominato e quindi direttamente disponibile per EL. Tuttavia, alla fine spesso si desidera consentire al "codice di supporto" di generare messaggi di facce o selezioni di handle (tabella), che sono tutte cose che non dovrebbero essere la preoccupazione di un puro servizio aziendale.
Un'altra scorciatoia comune consente al bean di supporto di contenere direttamente il codice aziendale (ad esempio, il gestore di entità che recupera le entità). Ciò rende difficile riutilizzare il codice aziendale, ma se l'app è banale e non è necessario riutilizzarla, potresti farla franca.
Ma lasciare che l'entità, ad esempio il bean backing, sia rara e anti ai modelli Java EE comuni.
Basta notare che il bean di supporto può restituire direttamente l'entità, quindi è ancora possibile utilizzare la convalida del bean. Non è assolutamente necessario per lo strano pattern "scatter/gather" che si è insinuato molto tempo fa (vedi il secondo esempio in this question).
E.g.
@ViewScoped
@ManagedBean
public class BackingBean {
private SomeEntity myEntity; // + getter
@EJB
private Service service;
@PostConstruct
public void init() {
myEntity = service.getSomeEntity();
}
public void save() {
service.save(myEntity);
FacesContext.getCurrentInstance().addMessage(..., ...);
}
}
Ipotizzando SomeEntity in un bean @Entity annotato, la convalida di fagioli può ora essere utilizzato su un facelet come:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
>
<h:body>
<h:form>
<h:inputText value="#{backingBean.myEntity.name}" />
<h:commandButton value="Save" action="#{backingBean.save}" />
</h:form>
</h:body>
</html>
Se c'è un vincolo sulla SomeEntity.name sarà convalidato.
Grazie per il tuo post, è utile ma hai un esempio completo di codice JSF che possiamo usare e capire il modo appropriato di scrivere l'app JSF o sarebbe bello se tu potessi indicarmi in qualche direzione. – Rachel
+1 per una risposta molto chiara che fornisce anche un contesto più ampio del problema –
"Basta notare che il backing bean può restituire l'entità direttamente, quindi è ancora possibile utilizzare la convalida del bean. Non è assolutamente necessario per la strana dispersione/raccogli il modello che è strisciato molto tempo fa. " Mi chiedo se potresti approfondire questo. Cos'è questo pattern 'scatter/gather'? È simile: ho sentito alcune persone sostenere una maggiore separazione tra la vista e il modello, e quindi mappano i campi di Facelets sulle proprietà dei bean di back (spesso primitive), quindi usano un servizio stateless per accettare le proprietà, eseguire la validazione, e popola e persiste l'entità. – DavidS