J2EE vs Spring
Ancora una volta si parla di J2EE vs Spring, ovvero di “heavyweight” vs “lightweight”, ovvero di Sun vs mondo open in senso più stretto. Secondo l’opinione ormai diffusa, viene associato un concetto di pesantezza allo standard J2EE (o JavaEE che dir si voglia).
Ma occorre fare un po’ di chiarezza. Stiamo parlando di due tecnologie (J2EE e Spring) quindi un punto è certamente vero: prima di tutto è una questione di scelta. Non esiste tecnologia vincente in assenza di un buon software architect e la scelta di quale tecnologia adottare dipende anche (e soprattutto) dal team di sviluppatori di cui si dispone.
Tutte le tecnologie richiedono una “learning curve” iniziale, ovvero un certo costo per l’apprendimento. Disponendo di programmatori Junior ad esempio l’approccio di Spring, POJO-oriented, è in qualche modo più immediato. Ma ciò non toglie che Spring sia comunque molto ricco e che occorre molto tempo per “dominare” tutte le tecnologie e i concetti in esso contenuti. Per contro J2EE costringe lo sviluppatore a conoscere abbastanza bene i dettagli del container (ad esempio il ciclo di vita degli EJB) e per tanto richiede sviluppatori più esperti.
In ogni caso non bisogna dimenticare che J2EE non è solo EJB ma anche altre importanti API come JTA, JMS and JMX. D’altra parte Spring sposa ovviamente le tecnologie open, come Hibernate, JDO per la persistenza o Burlan e Hessian per le comunicazioni remote.
Ma dato che lo sviluppo di un’applicazione web “vera” può richiedere ad esempio l’utilizzo di Struts/Spring/Hibernate o JSF/Spring/Hibernate o Struts/EJB perchè non unire il meglio delle varie tecnologie? Spring + JMS, JMX and JTA?
Insomma, meglio collaborare che farsi la guerra 🙂
Leggi anche l’articolo originale.