Limitações do @EJB?

[Leonardo3001]

[quote] Meu, de boa, o melhor é colocar a interface EJB dentro do managed bean. O framework Seam faz isso e Java EE te estimula a fazer isso, então pra que ficar negando?

Pq eu não concordo com suas explicações, pricipalmente com a primeira:

1) Conceitualmente, não existe diferença entre conhecer a interface do Delegate e conhecer a interface do EJB, os dois são semelhantes! Claro, são classes diferentes, mas seus métodos são parecidíssimos. Por isso, não existe nenhum “desacoplamento” quando você troca o Delegate pela interface EJB. Por isso, minha afirmação de que é inevitável que o cliente conheça a interface do negócio continua válida.

Dizer que o delegate é semelhante ao session, pra começar session é EJB e deleggate não…[/quote]

E é um direito seu não concordar com minhas explicações.

Mas lembre-se, não estou trocando um delegate por um session; no EJB 3, estou trocando um delegate por uma interface, o session é quem implementa essa interface, e o cliente não está sabendo da implementação de fato.

Apesar do título dizer que é uma limitação, eu vejo como um avanço o Java EE assumir certas responsabilidades para que o desenvolvedor escreva a aplicação com menos camadas.

Sugiro você ficar olhando para os posts da seção de metodologia do GUJ, sempre tem alguém criticando o desenvolvimento em camadas, você vai aprender que certos “atos de fé” na construção de aplicações web não funcionam direito na prática.