Quale ambito CDI deve essere utilizzato per le classi DAO e Service

Question

Sto provando a creare un'applicazione utilizzando solo JPA, CDI (OpenWebBeans + Deltaspike JPA module), JSF. Sto usando il CDI distribuito su Tomcat nello stesso modo in cui sono abituato a usare il framework Spring. Ho DAO chiamato GenericDAOImpl come questa (prime linee):

public abstract class GenericDaoJpa<T> implements GenericDao<T> { 
    private static final Log logger = LogFactory.getLog(GenericDaoJpa.class); 

    @Inject 
    protected EntityManager entityManager; 

    private Class<T> type; 

EntityManager viene iniettato utilizzando DeltaSpike JPA modulehttp: //deltaspike.apache.org/jpa.html. Questo genericoDao viene quindi ereditato da DAO (UserDao ecc.) In calcestruzzo, utilizzato dalle classi di servizio.

Ad esempio UserServiceImpl:

public class UserServiceImpl implements UserService { 

    private static final Log logger = LogFactory.getLog(UserServiceImpl.class); 

    @Inject 
    private UserDao userDao; 

    @Transactional 
    public void saveUser(UserDto user) throws UserServiceException { 
     try { 
      User u = new User(user); 
      userDao.create(u); 
     } catch (Exception e) { 
      logger.error("Error while creating user.", e); 
      throw new UserServiceException("Error while creating user."); 
     } 
    } 
} 

Utilizzando CDI questo modo sia DAO e classe di servizio avrà portata Dependent differenza in primavera dove sarebbero Singleton. Pertanto ogni client avrà una nuova istanza iniettata. Devo cambiare gli ambiti su DAO e le classi di servizio su ApplicationScope? Ma poi con le specifiche devo rendere serializzabili tutte le classi che vengono iniettate. In caso di classi di Dao questo potrebbe essere un problema, EntityManager dovrebbe quindi essere contrassegnato come transitorio? A

Sarei felice per qualsiasi raccomandazione.

Answer 1

@ApplicationScoped non ha rilevanza per Serializable, sono sempre in giro e non persistono mai sul disco. @SessionScoped richiederà la serializzazione a causa del comportamento degli oggetti di sessione HTTP.

Si consiglia di utilizzare un oscilloscopio poiché lasciare tutto dipende da perdite di memoria (non è mai chiaro quando un oggetto @Dependent viene rimosso). Se la tua applicazione è discretamente stateless, puoi usare @RequestScoped. @ApplicationScoped è necessario considerare che più client si connetteranno alla tua istanza.