Pessoal,
Gostaria de saber de vocês os motivos que me levariam em um projeto, web, a escolher por EJB3.0 e não apenas por Hibernate, por exemplo, na camada de negócio e persistência.
Fernando
Oi Fernando,
você poderia especificar melhor a sua pergunta? EJB 3.0 != Hibernate.
Claro,
Gostaria de saber quais são os argumentos que me leve, ao desenvolver uma aplicação web, a utilizar EJB, e não apenas JPA/Hibernate. Um dos motivos, é a parte de clusterização…Mas existem outros argumentos?? Eu sinceramente acho o uso de EJB uma complexidade a mais…
Não sei se vc conseguiu entender a questão…
Entendi. Bem, o EJB é o carro chefe da plataforma JavaEE da Sun e a sua arquitetura fornece um conjunto de serviços para aplicações coorporativas, como segurança, transações, cluster, agendamento e outros recursos. JPA está na especificação EJB 3.0 mas a Sun pretende torná-la uma especificação a parte, sem falar que você pode utilizar JPA para outros tipos de aplicações, como Desktop.
JPA se baseou no Hibernate e por ser uma especificação, algumas empresas a utilizam por esse motivo. O Hibernate ainda continua sendo muito mais robusto do que a JPA, fornecendo uma API muito mais abrangente. JPA e Hibernate são frameworks ORM, ou seja, para persistência. Persistência é um dos recursos que a arquitetura EJB abrange.
Como alternativa, existem frameworks no mercado que fazem o trabalho semelhante, e até as vezes melhor. Portanto, a escolha deverá ser minunciosamente decidida, a fim de que os recursos atendam aos requisitos do seu sistema.
Mas aí é que está a questão: Que requisitos são esses que me obrigariam a tomar a decisão pelo uso do EJB e não pelo uso do JPA/Hibernate??
[quote=Fernando Generoso da Rosa]Mas aí é que está a questão: Que requisitos são esses que me obrigariam a tomar a decisão pelo uso do EJB e não pelo uso do JPA/Hibernate??
[/quote]
Como eu falei anteriormente, EJB é diferente de JPA/Hibernate ou qualquer outro framework ORM. EJB são componentes de negócios que rodam em servidores de aplicações.
Você pode utilizar EJB sem JPA/Hibernate ou até mesmo sem JDBC, mudando o formato de persistência do seu sistema, como por exemplo em arquivos.
Então, para substituir o EJB, utilizaria o Spring??? Substituiria totalmente??
Perfeito.
Perfeito.[/quote]
A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.
Spring é um framework de IoC(dentre outras coisas mais que foram acrescentadas com o tempo), EJB tem como objetivo prover funcionalidades convenientes a um ambiente JEE (facilitade para clusterização, Controle de Transacional, componentização).
[]'s
[quote=GraveDigger]
A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.[/quote]
Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.
Leia a próxima MundoJava que você verá que o Spring é muito mais além do que um simples framework IoC.
Se você já está usando um servidor JEE, como Glassfish ou JBoss, eu não vejo nenhum motivo para preferir Spring a EJB, a não ser talvez se toda a equipe já estiver familiarizada com Spring. Se o padrão já provê tudo o que você quer, pra que ficar adicionando dependência?
Pessoalmente, eu acho que EJB 3 reduz a curva de aprendizado, porque passa para o container responsabilidades como controle de transação e injeção de dependências. Você pode preferir deixar essa parte no seu framework, mas eu acho que EJB está bem intuitivo.
[quote=rubinelli]Se você já está usando um servidor JEE, como Glassfish ou JBoss, eu não vejo nenhum motivo para preferir Spring a EJB, a não ser talvez se toda a equipe já estiver familiarizada com Spring. Se o padrão já provê tudo o que você quer, pra que ficar adicionando dependência?
Pessoalmente, eu acho que EJB 3 reduz a curva de aprendizado, porque passa para o container responsabilidades como controle de transação e injeção de dependências. Você pode preferir deixar essa parte no seu framework, mas eu acho que EJB está bem intuitivo.[/quote]
Sim, em nenhum momento eu disse que X é melhor do que Y. A minha resposta foi apenas para sanar a dúvida do Fernando. Tanto EJB como Spring são uma mão na roda para desenvolver aplicações enterprise.
[quote=rcarneiro][quote=GraveDigger]
A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.[/quote]
Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.
[/quote]
O “exemplo” de EJB que ele falou foi JPA, não EJB em sua totalidade, ele desconhecia EJB, até ai sem problemas, mas afirmando o que vc afirmou, dá a entender que de fato EJB limita-se ao que ele pensava, o que está incorreto.
Valeu a dica, talvez o Spring tenha mudado absurdamente nesse tempo que eu não estou utilizando-o.
Mas ainda discordo dele como alternativa ao EJB,hehe.
[]'s
[quote=GraveDigger]
Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post. [/quote]
Bem, o Rod Johnson criou o Spring justamente para atacar as falhas que ele encontrou nas versões antigas do JavaEE. O Spring tem suporte transação, segurança, AOP, Web services, agendamento, messageria, injeção de dependência e outros tipos de recursos.
O EJB também não tem todos esses recursos?
[quote=rcarneiro][quote=GraveDigger]
Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post. [/quote]
Bem, o Rod Johnson criou o Spring justamente para atacar as falhas que ele encontrou nas versões antigas do JavaEE. O Spring tem suporte transação, segurança, AOP, Web services, agendamento, messageria, injeção de dependência e outros tipos de recursos.
O EJB também não tem todos esses recursos?
[/quote]
Não todos esses, o Spring provê até alguns que o EJB não provê.
Mas qual a alternativa do Spring para um modelo de programação Stateful ?
[]'s
Prototype.