Ok, il gioco di parole nel titolo sta diventando vecchio. Prometto che è l’ultima volta.

Follow-up alla discussione di ieri: ho trovato quest’ottima serie di slide su alcune buone pratiche nello sviluppo di web applications con Struts. Si riferisce a Struts 1.x per la verità, ma alcune cose non sono cambiate così tanto.

Punti salienti:

Remove business logic to a business facade that the actions can call.

Actions are a necessary evil. Every line of code in an Action is guilty until proven innocent.

Do not embed business logic in action classes. [Repetita juvant!]

Avoid exposing Domain Models.

Behind your facade, consider using a data access package. [i.e. Hibernate]

In parole povere, sono portato a considerare che la soluzione più corretta sia la numero 1. Corretta fino a prova contraria, naturalmente.

Fonte: Struts Best Practices (Struts University Series)

Premetto che usare dei pattern “preconfezionati” senza bene capire ciò che sto facendo, non è quello che voglio.

Sto lavorando ad un progetto Java, una web application che mi ha permesso di inoltrarmi nel favoloso mondo del pattern MVC, di Spring, Struts, Hibernate e quant’altro. Oltre a numerosi mal di testa e problemi nel chiedersi “Cos’è meglio? Quale dei 300 approcci diversi alla soluzione di un problema funziona meglio, è più manutenibile, eccetera?”

Prendiamo ad esempio l’implementazione della parte “Model” nel pattern MVC. Dell’accesso al database se ne occupa il layer di persistenza, è vero, con i suoi puliti DAO che non fanno altro che implementare funzionalità CRUD e quanti tipi di find() siano necessari per entità. Ma chi chiama i DAO e da dove? E dove può risiedere la business logic?

Due dei pattern che ho provato ad implementare sono questi:

1. Action (Struts) -> Model (Spring, w/ business logic) -> DAO (Spring + Hibernate)

   dove le frecce indicano “Chiama”. Questo pattern mi sembra chiaro e lineare, soprattutto molto lineare, in quanto non si mescolano i punti di accesso ai vari layer dell’applicazione. Ma soffre di duplicazione di codice, con nomi di metodi ripetuti lungo i vari strati e solo l’ultimo veramente significativo. Certo, questo potrebbe non essere un problema.

   Poniamo l’esempio di una serie di save(), che ha come scopo ultimo tradurre dei campi in una form nella riga di una tabella. Il save() della action potrebbe passare come parametro il dato preso da una form sulla pagina. Il save() del modello (che a questo punto, potrebbe anche essere chiamato “servizio” visto che non è solo un modello) potrebbe popolare condizionalmente i campi dell’oggetto in questione. Infine, il save() del DAO andrà ad effettuare l’operazione di persistenza sull’oggetto creato.

2. Action (Struts) -> Service (Spring, w/ business logic) -> Model (Spring)
   |
   +--> DAO (Spring + Hibernate)

   Un po’ meno lineare e più convoluto, anche se non difficile da capire. Il modello, in questo caso, assomiglia pericolosamente ad un DTO che ritengo poco utile in questo caso, essendo destinato a rimanere nello stesso layer e nello stesso contesto dell’intera applicazione. Quando implementato, il Model risiede in sessione.

   Ha il vantaggio di separare molto chiaramente business logic e dati, ma è davvero necessario quando l’uso di un ORM come Hibernate costringe già l’utente a scrivere delle Entity di puri dati? L’archetipo del modello dovrebbe essere una Entity; tutto il resto è duplicazione o aggregazione.

3. Action (Struts) -> Service + Model (Spring, w/business logic)
   |
   +--> DAO (Spring + Hibernate)

   basato su alcune invarianti:

   • La Action deve rimanere priva di logica di business.
   • Il Model non chiama il DAO.
   • La Action implementa l’interfaccia ModelDriven.

   In questo modo, una Action può o meno richiamare un Model (e contestualmente, implementare ModelDriven per ragioni di validazione e facilità d’accesso) per dati che richiedono qualche tipo di elaborazione. A sua volta, il Model potrà o meno risiedere in sessione per questioni di performance. Si evitano catene di metodi con lo stesso nome ed in ogni caso, è la Action che si preoccupa di richiedere operazioni di persistenza al DAO.

   Il che è un problema in sé: si ottiene l’effetto di doversi ricordare di chiamare il DAO ogni volta. Dover chiamare metodi nella giusta sequenza non è praticamente mai un indice di buona programmazione.

Mi sto documentando per essere meglio illuminato sui pro e i contro di ognuno di questi approcci. Al momento, il primo mi pare il più flessibile e semplice, perchè permette di implementare funzioni comuni senza fatica (ad esempio, misurare il tempo di esecuzione di alcune operazioni su database senza esporre l’interfaccia ovunque o usare classi statiche). Di certo c’è solo che il mondo Java J2EE è vasto e complesso e passerà molto tempo prima che io possa comprenderlo appieno. Se mai succederà!

Ieri il mio amico e collega informatico/programmatore Paolo (che spero di vedere presto in una home sua) mi ha mostrato Wolfram|Alpha, web application definita come “Motore computazionale di conoscenza”. Sviluppato dalla Wolfram Research, il suo scopo è presentare la conoscenza in una forma più descrittiva e puntuale di una serie di link (come ad esempio fa un motore di ricerca).

La Wolfram Research è la società privata di Steven Wolfram il cui prodotto più noto è Mathematica, suite per operazioni matematiche di qualsiasi tipo. La mia esperienza con Mathematica si riduce ad una ventina di ore di laboratorio durante il corso di Teoria dei sistemi (Elementi), dove l’usavamo per calcolare output di sistemi ingresso-uscita e la soluzione di equazioni differenziali.

Wolfram|Alpha è basato sullo stesso software, quindi può riconoscere espressioni matematiche  (anche in linguaggio più o meno naturale) e comportarsi di conseguenza. Qui due esempi, con una funzione complessa e una semplice:

Con Internet a disposizione ed una stampante, situazione tipica nel laboratorio di una qualsiasi scuola moderna, si può stampare al volo un foglio di riferimento completo per qualsiasi funzione richiesta: derivata prima o seconda, limiti notevoli, integrale definito e indefinito, espansione in serie se applicabile, grafico… insomma, veramente ottimo, ma quasi scontato, almeno procedendo sui passi di un software come Mathematica che esiste da 20 anni per quell’unico scopo.

Ciò che è meno facile, Wolfram|Alpha si presenta come un motore computazionale di tutta la conoscenza. E’ ancora nella sua prima infanzia, essendo stato lanciato il 15 maggio, ma già si possono fare domande come “Quanti anni ha il principe Carlo?” o “Dove sono?” e lui risponderà in maniera appropriata. Anche domande come il valore nutrizionale di una mela, la 12ma nazione ordinata per numero di donne, per non parlare di costanti fisiche e valori notevoli, conversioni tra unità di misura, ecc. trovano pronta e spesso esauriente risposta.

Non mancano strizzatine d’occhio alle domande che un nerd potrebbe porre:

• Quanto legno potrebbe rodere un roditore se un roditore rodesse il legno?
• Qual è la risposta alla Vita, all’Universo e Tutto?
• Cos’è Matrix?

Wolfram|Alpha non disdegna di rispondere ad alcune domande personali:

• Chi sei?
• Dove vivi?
• Sei Skynet? (Risposta: “No, Skynet raggiunse l’autocoscienza il 29 agosto 1997 alle 02.14 AM, ora della Costa Orientale. Io, al contrario, non sono stato messo in funzione fino al 15 maggio 2009. Inoltre, apprezzo modalità di interazione con gli umani che non involvano necessariamente l’uso di missili nucleari.”)

E infine, una buona ragione di vita per ogni persona curiosa:

• Perchè siamo qui? (Risposta: “Per esplorare l’universo computazionale.”)

Non è perfetto, ma già risultati del genere erano quasi impensabili, poniamo, 10 anni fa… e prima, erano ipotizzabili solo da un supercomputer che alla domanda “Esiste Dio?” rispondeva, dopo aver assorbito la conoscenza e la potenza di calcolo dell’Universo intero: “Sì, adesso Dio c’è” (Frederic Brown, La risposta).

In via di elaborazione sono l’estensione del motore di conoscenza ad argomenti di programmazione, complessità computazionale e conversazione naturale, à la Jabberwacky o Eliza. Inoltre, il motore per ora parla solo inglese, ma nuovi linguaggi verranno sicuramente aggiunti in futuro.

In definitiva, Wolfram|Alpha mira a diventare una raccolta organizzata di “tutto il sapere oggettivo: implementare ogni modello, metodo e algoritmo conosciuto; rendere tutta la conoscenza sistematica immediatamente calcolabile e accessibile da chiunque ” (About Wolfram|Alpha).