È preferito Spring + Hibernate invece di EJB 3?

Ho la sensazione che ogni volta che iniziano nuovi progetti JEE (dove queste tecnologie sarebbero applicabili), le persone preferiscono utilizzare una combinazione di Spring + Hibernate invece di EJB 3.

Sembra che ai programmatori junior venga persino consigliato di optare per questo invece di EJB.

Questa preferenza personale o ci sono ragioni pertinenti per essa? (ad es. cicatrici personali create da versioni precedenti di EJB che hanno causato sfiducia in EJB o rigonfiamento della tecnologia rispetto a motivi di prestazioni o curva di apprendimento)?

I framework EJB 3+ sono in realtà piuttosto buoni in quanto sono arrivati ​​insieme a JPA come risposta per i framework di persistenza configurati con annotazioni, così come il CDI che consente l'iniezione di dipendenza configurata con annotazioni. Aggiungete anche sopra quella Saldatura. D'altra parte, la primavera si sta appena avvicinando al gioco con la configurazione tramite annotazione.

Detto questo, lo storico contraccolpo contro EJB1 e 2 non dovrebbe essere scontato. Non solo non sono riusciti a risolvere i problemi con la scrittura di applicazioni aziendali, ma hanno fallito in modo spettacolare . È stato un completo fallimento da parte dei progettisti avere un impulso sui veri problemi che devono affrontare gli sviluppatori di applicazioni aziendali e Web e, a loro volta, fornire soluzioni di cui avevano effettivamente bisogno.

A ciò si aggiunge la diffidenza che ci sono alcuni gravi cambiamenti e instabilità con l'attuale direzione di Java in questo momento e la mancanza di fiducia negli attuali amministratori e proprietari del vecchio Sun JVM, in Oracle. Molte persone non credono che Oracle migliorerà su Java e guiderà la direzione e c'è anche il timore che Apache Software Foundation possa semplicemente buttare la spugna. Sempre più persone stanno cercando OpenJDK per il futuro di Java, ma non è proprio dove deve essere per l'adozione Enterprise.

Alcuni vedono tutto ciò come l'odore della morte, poiché le applicazioni aziendali sono i motivi principali per cui Java è storicamente il linguaggio di programmazione n. 1 al mondo da sempre. Questo è il motivo per cui Microsoft sta guadagnando così tanto terreno contro Java con le tecnologie .NET.

Gli sviluppatori di applicazioni Java non basati sull'impresa si stanno orientando sempre più verso OpenJDK e altri framework open source per aiutare a costruire le loro soluzioni e alcuni non guardano mai indietro. Si potrebbe dire che è un caso di troppo tardi per riportare JEE in prima linea nella legittimità, anche se tecnicamente JEE può e fa fronte ai piedi con l'applicazione Spring comparabile.

EJB ha molti bagagli. Parte di quel bagaglio deriva dal fatto che era indirizzato al pubblico sbagliato. L'altra parte era che le prime due versioni erano una vera schifezza.

Se si osservano le versioni EJB originali, il progetto prevedeva che uno sviluppatore EJB potesse creare una soluzione pacchettizzata che potesse essere utilizzata in qualsiasi contenitore conforme a EJB. Per un negozio interno, questo livello di astrazione non era necessario. Era una soluzione perfetta per creare un fiorente mercato per i fornitori di componenti EJB di terze parti. Tuttavia, i venditori di container erano troppo zelanti nella loro commercializzazione e stavano facendo tonnellate vendendo il loro prodotto come soluzione praticabile per lo sviluppo quotidiano. Ciò equivarrebbe a costruire tutto il codice dell'applicazione come componenti COM +.

Per ulteriori informazioni sulle specifiche J2EE originali, la maggior parte dei fornitori coinvolti disponeva di server CORBA e desiderava sfruttare tali prodotti in futuro. Le specifiche EJB sono state costruite sul protocollo IIOP (in realtà Java RMI che era un layer sottile su IIOP). CORBA era già stato respinto a causa della sua complessità e EJB era solo CORBA sotto mentite spoglie quindi ha portato con sé molti dei problemi che CORBA aveva. In realtà, le astrazioni di EJB hanno reso più difficile lavorare di quanto non sarebbe stata una pura implementazione CORBA.

Una volta che la gomma ha colpito il marciapiede, la gente ha capito che le prestazioni con EJB erano atroci. Con ogni chiamata che è una chiamata remota e la difficoltà persino di avviare l'applicazione in modo corretto per iniziare, le persone hanno rapidamente cercato alternative. Hibernate e Spring in esecuzione in un contenitore JSP sono diventate la soluzione.

EJB 3 "ha adottato" questo approccio. Ma è ancora un compromesso generico che non offre molti vantaggi. Non esiste ancora un mercato di componenti EJB di terze parti, quindi non ha davvero senso utilizzare un contenitore EJB per creare la soluzione.

Per farla breve. Sebbene EJB 3 sia un notevole miglioramento rispetto alle prime due iterazioni, non fornisce ancora abbastanza benefici per superare i costi.