[quote=Alessandro Lazarotti][quote=legionarioba][quote=Alessandro Lazarotti][quote=legionarioba]
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…[/quote]
Não defendendo ninguém, mas pq usar um EJB como “DAO” (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?[/quote]
Não é questão de usar EJB com Dao…Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural…a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB…O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo… Este é o equívoco…
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)…[/quote]
Mas legionarioba], não é pq é EJB que precisa ser “remote”, ele pode ser “local”. Tbm não é pq vc usa EJB que você não pode utilizar qualquer framework de DI para injeção de classes utilitárias.[/quote]
Só quis dizer que injeção de dependência com “EJB puro” só funciona com quem está anotado com @EJB (não entrei no mérito de ser local ou remote). Ainda sim, conceitualmente uma camada de acesso a dados não é um EJB(ainda que eu possa minimizar isso utilizando como local)… E claro, além do Spring poderia ser qualquer outro frame de DI…(mas já que o tópico é sobre Spring… 
)
Meu único pensamento é: não fazer de uma classe qualquer um EJB(ainda que local), pra usar DI…