Duvida EJB 3

Buenas;

A maioria dos padroes pode ser descartada, pois o Java EE 5 deu uma boa simplificada.

Delegate vc nao precisa mais com a injecao de dependencia:

@EJB InterfaceRemota objetoRemoto

Talvez o Session Façade assume aí uma posicao mais evidente, visto que o EJB em si pode ser um coordenador do processo de controle do modelo de domínio (Aí eu ainda tenho uma certa dúvida).

O DAO na minha opinião definitivamente pode ser eliminado visto que o EntityManager da JPA faz todo o trabalho sujo.

Com o DAO pode ir embora o TO/DTO pois a entidade é um pojo…

O interessante é a simplicidade, os padroes (Core J2EE - Que foram adequados para se adaptar à complexidade do EJB 2.X) diminuiram e com eles a complexidade em desenvolver aplicações enterprise

Olá colega, bom, vai minha opnião…

Padrões vão sempre existir independente de versão que vc vá utilizar de framework…

Sempre utilizamos os mesmos para resolver alguns problemas ou mesmo para desacoplamento das camadas…

Em nossa arquitetura do BicBanco, que estamos entregando, temos :

No lado client: as interfaces de negócio, excessões, Business Delegate e o view

No lado model: facade, business object

No lado persistence: interfaces DAO, implementações e entidades EJB 3(jpa)

Bom isso aí vai de como vc quer que a coisa esteja organizada

[s]
baiano

Estou meio confuso, vc criou as interfaces dao, e as emplementou utilizando EntityManager, certo ? Ouve alguma implementação de um dao generico, ou são todos especificos de cada negocio ?
Outra coisa, pra mim as classes que utilizam os EntitysManager são as classes de negocio certo, ( seria as implementações das InterfaceManager como no Spring , ou viajei ? )

Opa , e acabo surgindo mais uma duvida, na minha aplicação cliente estarei utilizando jsf, como meu controle ira acessar os componentes de serviço, usando um SeviceLocator, ou @EJB pra fazer injeção ??? isso fica na Classe de controle, ou e aconselhavel fazer um fachada ??

Meus Deus quanta duvida hahah !

Ressucitando!!!

Minha dúvida é a seguinte: para um SessionBean StateFull que serve a um cliente específico, no meu caso a um cliente web, se ele possui variáveis de instância (recursos do ENC, Entitys, etc), como vai ser o comportamento dele para milhares de requisições? Por debaixos dos panos, o que me garante que o SessionBean Statefull não vai se perder entre essas milhares de threads?

Nesse sentido, se tenho uma classe SessionBean Stateless (funcionando como um DAO):

@Stateless
public class A_Bean implements A_BeanLocal {
   @PersistenceContext
    EntityManager em;

    public void salvar(Object o) {
        em.save(o);
    }
}

E outra classe SessionBean Stateful:

@Stateful
public class MySessionBean implements SessionBeanRemote {
   @EJB
   private A_BeanLocal beanLocal;

   @TransactionAttribute(TransactionAttributeType.REQUIRED)
   public String atualizarOuCadastrar(Entity e) {
        if(e!=null)
          beanLocal.salvar(e);
   }
}

Como fica a transação que é iniciada no MySessionBean? Ela é propagada para o método salvar de forma transparente?

Valeu

Bem, pelo que estudei eu NÃO me devo preocupar com o problema das milhares de requisições ao EJB, correto? Se ele não se virar com isso, nada mais consegue…

E as transações, ainda é um pouco misterioso, vou tentar ser mais claro, imaginem que eu carreguei uma entidade X com os dados de um registro da tabela T. Como o EJB trata desse registro X caso no mesmo momento uma outra transação resolva dar um UPDATE no registro?

Ele usa um RoWLock? Uma outra transação acessará uma entidade com dados inconsistentes?