O Spring + Hibernate é preferido em vez do EJB 3?

É minha percepção de que sempre que novos projetos JEE são iniciados (onde essas tecnologias seriam aplicáveis), as pessoas preferem usar uma combinação de Spring + Hibernate em vez de EJB 3.

Parece que os programadores juniores são aconselhados a fazer isso em vez do EJB.

Essa é uma preferência pessoal ou existem razões pertinentes para isso? (por exemplo, cicatrizes pessoais criadas por versões anteriores do EJB que causavam desconfiança no EJB ou inchaço da tecnologia versus razões de desempenho ou curva de aprendizado)?

As estruturas EJB 3+ são realmente muito boas, pois vieram junto com o JPA como resposta para estruturas de persistência configuradas com anotações, bem como com o CDI que permite injeção de dependência configurada com anotações. Você também adiciona em cima dessa solda. A primavera, por outro lado, agora está alcançando o jogo com a configuração através de anotações.

Dito isto, a reação histórica contra o EJB1 e 2 não deve ser desconsiderada. Eles não apenas falharam em resolver os problemas com a criação de aplicativos corporativos, mas falharam espetacularmente . Foi um fracasso completo da parte dos designers avaliar os verdadeiros problemas enfrentados pelos desenvolvedores de aplicativos corporativos e da Web e, por sua vez, fornecer as soluções que eles realmente precisavam.

Acrescente a isso a desconfiança de que haja alguns sérios abalos e instabilidades com a atual direção do Java neste momento e falta de fé nos atuais administradores e proprietários da antiga Sun JVM, no Oracle. Muitas pessoas não acreditam que a Oracle irá aprimorar o Java e liderar a direção, e também existe o medo de que a Apache Software Foundation possa simplesmente jogar a toalha. Mais e mais pessoas estão procurando o OpenJDK para o futuro do Java, mas simplesmente não é onde precisa estar para a adoção da empresa.

Alguns vêem tudo isso como o cheiro da morte, pois os aplicativos corporativos são as principais razões pelas quais o Java é historicamente a linguagem de programação número 1 do mundo há tanto tempo. É por isso que a Microsoft tem conquistado tanto terreno contra as tecnologias Java com .NET.

Os desenvolvedores de aplicativos Java não baseados em empresas estão se voltando cada vez mais para o OpenJDK e outras estruturas de código aberto para ajudar a construir suas soluções e alguns nunca estão olhando para trás. Pode-se dizer que é um caso de muito pouco tempo para colocar o JEE de volta na vanguarda da legitimidade, mesmo que tecnicamente o JEE possa e esteja em pé de igualdade com seu aplicativo Spring comparável.

EJB tem muita bagagem. Parte dessa bagagem vem do fato de ter sido direcionada ao público errado. A outra parte era que as duas primeiras versões eram uma porcaria total.

Se você olhar as versões EJB originais, o design era que um desenvolvedor de EJB poderia criar uma solução empacotada que poderia ser usada em qualquer contêiner compatível com EJB. Para uma loja própria, esse nível de abstração era desnecessário. Era uma solução perfeita para criar um mercado próspero para fornecedores de componentes EJB de terceiros. No entanto, os fornecedores de contêineres eram excessivamente zelosos em seu marketing e estavam produzindo toneladas vendendo seu produto como uma solução viável para o desenvolvimento diário. Isso seria o equivalente a criar todo o código do aplicativo como componentes do COM +.

Para obter mais informações sobre as especificações originais do J2EE, a maioria dos fornecedores envolvidos tinha servidores CORBA e queria aproveitar esses produtos no futuro. A especificação EJB foi construída sobre o protocolo IIOP (na verdade, Java RMI, que era uma camada fina sobre IIOP). O CORBA já havia sido rejeitado devido à sua complexidade, e o EJB estava apenas disfarçado pelo CORBA, o que trouxe muitos dos problemas que o CORBA apresentava. Na verdade, as abstrações do EJB tornaram mais difícil trabalhar do que uma implementação pura do CORBA teria sido.

Quando a borracha atingiu o asfalto, as pessoas perceberam que o desempenho com o EJB era atroz. Com cada chamada sendo remota e com a dificuldade de colocar o aplicativo em funcionamento corretamente, as pessoas rapidamente procuraram alternativas. Hibernate e Spring em execução em um contêiner JSP se tornaram a solução.

O EJB 3 "adotou" essa abordagem. Mas ainda é um compromisso genérico que não oferece muitos benefícios. Ainda não existe um mercado de componentes EJB de terceiros, portanto não faz sentido usar um contêiner EJB para criar sua solução.

Longa história curta. Embora o EJB 3 seja uma grande melhoria nas duas primeiras iterações, ele ainda não fornece benefícios suficientes para compensar os custos.