Eu odeio EJB-QL, eu odeio ejbSelect

EJB não seria uma conspiração para se vender application servers ? Você realmente precisa de EJB ?

Acorde todo o dia e faça essa pergunta a si mesmo.

Eu me faço esta pergunta com uma freqüência muito alta.
Ok, alguém vai vir aqui dizer que EJBs são muito importantes porque deixam muito trabalho sujo transparente, que poderia ser muito pior, que EJBs permitem (com uma certa transparência) clusterização, fail-over, controle de transações, etc etc… Eu não estou questionando o que EJB permite ou não ser feito nem com qual grau de facilidade. A questão é: nos inúmeros projetos em que a tecnologia Java pode ser aplicada, qual a porcentagem de uso que cabe aos EJBs e qual a porcentagem de importância dada a eles? Em outras palavras, será que o marketing feito sobre eles não é superior ao seu real ganho/uso?

Eu acho EJB uma excelente tecnologia… E deve ser utilizado com coerência.

Não são todas as aplicações que precisam de EJB, nem todas as aplicações necessitam de um AppServer decente…

Se a criticidade for baixa, o JBOSS para aplicações JSP+SERVLET+JB, ele mesmo server…

Se a criticidade da aplicação pode custar alguns US$, melhor usar um Sun One, ou IBM ou Oracle ou BEA com EJB…

[]'s

Oziel, já tinham me falado que você não gostava do JBoss :D. Mas a questão não é essa. A questão é que a EJB-QL não é realista para pesquisas em grandes sistemas. O problema é a especificação, não a implementação.

bom, no EJB2.1 vai melhorar bastante, mas por enquanto, você pode utilizar JCA (Java Conector Architecture) para resolver parte do problema, se não me engano a JCA ja é obrigatoria para o J2EE 1.3, mas não tenho certeza, pelo menos o WebSphere, Sun One e JBOss eu tenho certeza que suportam JCA

Pessoal,
essa discussao nao leva a lugar nenhum , pois que pode ser bom pra mim, pode nao ser bom pra vc e vice-versa, eu acho valido sim discutir a tecnologia e tentar buscar solucoes melhores para a implementacao, no caso do EJB-QL eu o uso e quando ele nao me atende eu uso o JBOSS-QL e quando ele nao me atende eu uso DECLARED-QL e por ultimo JDBC, e te digo que raramente preciso chegar na ultima opcao!!

Em geral , quando se comeca a fazer comparacao entre AppServers / EJB e outras tecnicas (hibernate, jdo), o pessoal fica sempre batendo na mesma tecla: EJB-QL eh um lixo, precisa de um appserver, blablabla.

O mais importante, o que realmente os appserver/ejb revolucionaram eh a criacao da Programacao Declarativa. Uma penca de funcionalidades, que deveriam ser implementada pelo programador passaram a fazer parte do ambiente de deploy e descritos em arquivos XML.

Assim, hoje em dia, voce cria seu EJB, e separadamente diz que metodos vao ter que tipos de comportamento transacional. Voce tambem chega, ainda em granularidade de metodo dizer que perfil de usuario vai poder fazer uso de metodo (administrador ou usuario). Isso tudo sem precisar mexer em uma linha de codigo, somente no descritor.
Nas outras tecnologias isso tudo precisa ser explicitada pelo programador, na forma: aqui comeca minha transacao , comando1, comando2 , commit. Ou no caso de seguranca usando um if (!admin) return.

O EJB QL ta evoluindo. Logo ele sera o suficiente para a maior parte das aplicacoes (se ja nao eh).

Agora, se realmente, seguranca, transacoes, filas de mensagens, nada disso for interessante no seu sistema, uma abordagem totalmente web, com um hibernate ou jdo talvez seja uma melhor abordagem.

Mas nao va reeinventar a roda. Deixe o servidor de aplicacao fazer o trabalho sujo por voce. Deixe ele fazer os if (!admin) return, fazer os begin() commit() rollback().

Concordo plenamente com o tanque…

E sa facilidades da J2EE são do c…lho… Muito fácil escrever software robusto e escalável.

[]'s

é verdade, mas também pode ser esforço inutil se o sistema não precisar disto
gosto muito do J2EE, de EJBs e tudo o que vem junto, mas é preciso ver se o software realmente necessita de todos estes recursos