Jso

Ancora a proposito di web framework… discorso inflazionato è vero ma a quanto pare tutt’altro che concluso! Il topic in questo caso è se in una web application sia meglio codificare tutto in una action oppure separare nettamente la web logic dalla business logic. La risposta parrebbe ovvia, ma non tutti sono dello stesso avviso.
Si possono catalogare fondamentalmente 4 approcci:

1. Due classi: 1 action basata (*) sul framework e 1 business logic non basata sul framework
2. Due classi: 1 action non basata sul framework e 1 business logic non basata sul framework
3. Una classe: action e business logic nella stessa classe basata sul framework
4. Una classe: action e business logic nella stessa classe non basata sul framework
   (*) si legga “che estende classi del framework”

Tra tutte l’approccio preferito è sicuramente il numero 1, la 2 rappresenta il totale disaccoppiamento (ad esempio in Struts 2 / Webwork le azioni possono essere POJO e quindi totalmente disaccoppiate dal framework), mentre 3 e 4 sono generalmente considerate bad practise. Esistono sicuramente buone ragioni per disaccoppiare la business logic dalla action:

• Testability: se disaccopiata la business logic può essere testata in maniera indipendente (es. JUnit)
• Web services: la business logic può essere utilizzata in un web-service o in servizi remoti
• Caching: riferito alle business facades

Mentawai (un framework ad approccio programmatico con supporto per l’injection di cui esiste anche una versione Ruby) sembra offrire la libertà sufficiente per implementare tutti gli approcci (1,2,3,4). A voi la scelta…

Leggi anche l’articolo originale.

Una lunga discussione sull’ennessimo web framework, Apache Wicket che viene qui paragonato al “fratello” Apache Tapestry, con divagazioni su JSF, GWT e sull’onnipresente Struts ovviamente. Tra i suoi punti di forza e innovazioni rispetto agli altri web framework vi sono:

• Un eccellente supporto built-in ad AJAX;
• La capacità di modificare la struttura delle pagine programmaticamente;
• Perfetta separazione tra codice e templates (i templates non possono contenere codice);
• Un approccio object-oriented
• Facile apprendimento (per developers Java-oriented)

Naturalmente ci sono pro e contro, come in ogni cosa. Ma la principale ragione dell’esistenza di Wicket è che non esistono altri web framework programmabili in puro codice Java (quasi tutti seguono piuttosto il classico modello dichiarativo, con file di configurazione XML ad esempio). Naturalmente poi è anche questione di gusti, ma gli impatti più evidenti si hanno nell’ottimizzazione e nella versatilità del codice. In ogni caso anche Wicket, come pure Tapestry, Freemarker, JSF (con Facelets) e gli altri framework component-oriented rappresenta una valida alternativa ai precedenti framework Model 2 tipo Struts, tanto per citarne uno famoso 🙂

Leggi anche gli articoli originali: 1, 2 e 3

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.

Ecco un’ottima introduzione a Spring 2.0, l’attuale release di quel che è, ad oggi, probabilmente il miglior Framework open-source disponibilile in ambito Java… molto ricco, completo, configurabile, estensibile e soprattutto a differenza di molti altri non destinato solo allo sviluppo di web applications. Quantomeno da provare…

Nonostante l’età e il giudizio abbastanza diffuso che non sia più all’altezza delle moderne applicazioni web, Struts continua ad essere il framework MVC più utilizzato.

Intanto cresce l’utilizzo di JSF promosso da Sun, benchè anche questo abbia i propri detrattori, cresce l’utilizzo di Spring MVC (che sembra molto buono) e continuano ad essere utilizzati gli altri framework più o meno consolidati (Tapestry, Webwork) mentre emergono i framework rich client (Wicket, Echo2, Webstart) o, dando uno sguardo ad altri linguaggi,  RoR (Ruby on Rails) di cui molto si parla.

Ma Struts rimane, e sarà difficile scalzarlo. Proprio come il COBOL 🙂

Leggi anche l’articolo originale.