lunedì 20 agosto 2007

Alla ricerca del Santo Graal...

In questo periodo guardo con sempre più interesse a Grails. Tutto è cominciato quando ho deciso di approfondire le mie conoscenze sui web framework di tipo fronted per Java.
Da lì è partita sul serio la ricerca del Santo Graal. Quando cominci a cercare un framework per Java, sai quando cominci ma non sai quando finisci. E soprattutto con cosa finisci.

La mia esperienza attuale è limitata al lato backend dei framework. Ho usato con estrema soddisfazione Andromda e Spring, e Hibernate per l'accesso ai dati.
Anche queste scelte non sono state facili, ma in un certo senso è stato + immediato. Primo, perchè Spring e Hibernate sono standard de facto (e quasi quasi anche per diritto :-) ). Secondo, perchè dovevo cominciare a lavorare su un progetto e mi sono fidato subito del mio istinto.
Per Andromda è stato un caso, uno di quei casi che ti cambiano la vita :-)
Andromda è fenomenale, ha permesso la scrittura e gestione di un framework che supera le 150 entità, persistenti e non, con servizi di tipo J2EE, interfacciamento ai webservice.

Con i framework frontend la cosa è più difficile: ce ne sono una pletora, tutti validi e non c'è una reale direzione della comunità Java. Escludendo naturalmente Struts, che credo abbia fatto il suo tempo:
  • Click, Echo2, ThinWire: tutti ottimi prodotti, ma orientati ad applicazioni rich client piuttosto che generici siti/portali
  • GWT: uuhhmm le RPC mi danno garanzia di scalabilità?
  • OpenLaszlo: è un discorso a parte... ci giochiccherei volentieri, ma il tempo disponibile non me lo consente :P
  • Tapestry, Wicket(*): interessanti, l'idea di avere pagine HTML prive di elementi dinamici (il comportamento dinamico si ottiene con opportuni id nei tag HTML) dovrebbe ridurre le interferenze con i grafici.
    Di Tapestry però ho letto di complessità di configurazione e questo va contro la mia idea di buona progettazione. Un buon framework dovrebbe rendere semplici le cose semplici, e non troppo difficili le cose complesse. Per questo ho escluso Struts a priori.
    Il rischio è l'effetto "Inner-Platform": con lo scopo di rendere estremamente flessibile un componente di un sistema, lo si rende "un sistema dentro il sistema", complesso quanto il problema che si vuole risolvere.
    Il che a mio parere è blasfemo.
  • Stripes, ZK, Struts2, RIFE: andiamo già meglio (di RIFE non sono sicuro), c'è già una discreta applicazione dei principi di convention over configuration. Escluso Struts2 su cui non ho ben capito l'effettiva validità (e la home page che scimmiotta il Web 2.0 senza riuscirci), mi sono orientato su Stripes che mi pare abbia una comunità più ampia di RIFE e ZK. Una comunità più ampia significa bug risolti in fretta, disponibilità di articoli, faq, soluzioni a problemi complessi, tutti aspetti da tenere presente per applicazioni di produzione.
Stripes è quindi il prodotto che mi permetterebbe un approccio più moderno, ma abbastanza conservativo da non rischiare di cacciarmi nei pasticci.
Mi riferisco a portali web tipici, senza particolari richieste di interazione con l'utente. In applicazioni più tipicamente client, guardo con curiosità a ThinWire.
Ma tutto quello che è elencato (meno del 50% di tutto quello che in realtà si trova) non è affatto da scartare. L'ideale è che ogni esigenza venisse risolta con lo strumento più opportuno. In realtà si fa riferimento a quei 2-3 strumenti affermati ognuno per una certa tipologia di prodotto.

Attualmente io mi orienterei così:
  • Portale più o meno complesso, con poca logica applicativa e tipicamente web (per es. il classico sito di ecommerce): Stripes/Struts2/RIFE
  • Portale complesso, molto orientato ai dati (in realtà una trasposizione web delle applicazioni client, per es., la gestione di un magazzino): ThinWire/Click
  • Portale semplice, con logica tipicamente web anche abbastanza complessa (per es., gestione di un calendario online, o uno storage remoto con upload/download): Rails/Grails
Mi fermo qui. Ho vomitato tutto il mio giro mentale che mi ha portato a scoprire questi due progetti e ad intrappolarmi in un bivio: è vero quanto ho scritto alla fine? Rails/Grails sono veramente aggeggini con cui trastullarsi, o possono tranquillamente prendere il posto dei blasonati Stripes e Struts 2?

(*) Ricordavo male: di Wicket non mi aveva lasciato perplesso la complessità di configurazione (effettivamente Wicket è semplice), semmai la sua natura Java-centrica. Non so quanto mi convinca un portale che richieda, per ogni manutenzione, l'intervento su codice Java, con relativa compilazione, deploy ecc

2 commenti:

Nazzareno ha detto...

Ciao!
Ho letto con interesse il tuo:"Alla ricerca del Santo Graal", sono uno studente d'informatica e mi piacerebbe sapere qualcosina in più riguardante la tua esperienza con AndroMDA. Ho visto che lo classifichi come un framework backend, cosa intendi per framework backend?
Sbaglio se dico che è uno strumento ottimo per mettere velocemente sù un applicazione basandosi sul modello ma poco efficiente o difficile da utilizzare per lo sviluppo dell'interfaccia web e quindi la gestione della navigazione tra pagine ecc..?
Un'ultima domanda ;-) secondo la tua esperienza è possibile utilizzare AndroMda per lo sviluppo di un'applicazione desktop che memorizza i propri dati su file? In particolare per quanto riguarda lo sviluppo della GUI dell'applicazione?

Perdonami per l'invadenza e ti ringrazio in anticipo se avrai la pazienza di rispondermi.

Saluti.

Pietro Bonanno ha detto...

"framework backend" è un termine che mi sono inventato io :-)
Intendo dire che è un framework + adatto allo sviluppo dello strato interno di un'applicazione n-tier. Per la mia esperienza, AndroMDA dà il meglio nello sviluppo della parte di accesso alla base dati e nei service. Nella parte frontend, abbiamo cercato di capire se AndroMDA fornisse la flessibilità necessaria, ma non ci è sembrato. Dopotutto è un prodotto sviluppato da 3-4 persone.
Quindi alla tua seconda domanda rispondo che sono d'accordo. Io straconsiglio AndroMDA per il backend, andrei + cauto per il frontend.
Per la terza domanda, ti direi di evitare. AndroMDA usa Hibernate per la persistenza, che supporta anche XML, quindi in teoria sarebbe possibile.
Però il codice generato fa pesante uso di HQL, ed è orientato all'utilizzo classico con server DB.
Non sono sicuro ma non credo che Hibernate supporti HQL con la persistenza XML.
Un'applicazione desktop ti direi di svilupparla con meno stratificazioni, se proprio vuoi usare Hibernate, ti conviene Hibernate Synchronizer su Eclipse. Ma per la persistenza su XML eviterei del tutto Hibernate e andrei alla ricerca di framework specifici.
Ho risposto sinteticamente, se qualcosa non è chiaro, parliamone :-)