Se pensate che la beta di Safari 4, con la tanto discussa implementazione dei tab, fosse qualcosa di negativo, guardate questo screenshot della pros­sima versione di Office e poi correte a prendere qualcosa contro il mal di mare.

Siamo nel 2009, Barack Obama è il primo pre­sidente nero degli Stati Uniti d’America e la Microsoft usa ancora l’icona del floppy? Non parliamo del “ribbon”: una discarica di icone.

Com’è pos­sibile arrivare a cose del genere?

Altri commenti.

In uno dei post pre­cedenti accennavo al fatto che il giudizio sui domain model — e di conseguenza sugli ORM — tiene conto di criteri di ordine diverso: ci sono ragioni teoriche — di principio, direi — e ragioni pratiche.

Per quanto riguarda le ragioni teoriche credo di essermi già dilungato abbastanza, mentre sulle ragioni pratiche abbiamo cominciato a parlarne in relazione al caching. Oggi vorrei discuterne un’altra di tipo pratico. 

Uno dei modi di analizzare la struttura di un’applicazione è quella di ragionare per livelli.  Prendendo spunto da Fowler, abbiamo: un livello di pre­sentazione, uno di sorgente dei dati e uno con la cosiddetta domain logic. Grosso modo, pos­siamo dire che il primo livello corrisponde al browser, il secondo all’application server, il terzo al database.

Sorvoliamo su molti dettagli (ad es. se considerare il JavaScript che gira nel browser o la stored procedure nel database come facenti parte della domain logic o meno ecc.) e concentriamoci su quello che potremmo chiamare il tasso di mutazione nei vari livelli.

Sul lato del browser abbiamo la combinazione HTML+CSS+JavaScript da tempo immemore. Da qualche anno, con AJAX, la porzione di JavaScript è cresciuta a dismisura ed è cambiato il modo di considerare JavaScript come linguaggio; l’HTML è pas­sato attraverso varie revisioni e ramificazioni. Tuttavia, pos­siamo dire che nel complesso è cambiato relativamente poco.

All’estremo opposto abbiamo uno scenario simile. L’SQL, con i suoi limiti, le sue imperfezioni e i suoi diversi dialetti è certamente un qualcosa in continua evoluzione, ma senza scos­soni e in un quadro concettuale molto stabile. Altrettanto stabili sono le installazioni: una volta messo in piedi, è difficile che si passi ad un altro sistema.

Se guardiamo al livello intermedio troviamo invece una situazione completamente diversa. Abbiamo a disposizione tutti i linguaggi pos­sibili, con tutti gli approcci pos­sibili (ho perso il conto dei framework web in Java), che mutano a velocità sostenuta.

Non solo. L’avvento di AJAX ha spostato il baricentro verso il browser, sottraendo funzioni al livello intermedio, sino ad arrivare ad architetture come CouchDB, in cui questo livello non c’è proprio più.

E quindi mi sono fatto la domanda inevitabile: perché investirci ancora risorse? Ha ancora senso?

Che la carta stampata non se la passi bene, non è una novità.

Che però il design possa dare incrementi a due cifre dei lettori, beh, questa sì che è una novità. Guardate qui!

Fra i vantaggi che sono solitamente ascritti agli ORM c’è il caching. Si sfrutta la pos­sibilità di creare in memoria una rappresentazione persistente di righe nel database, sotto forma di un grafo di oggetti, per evitare di dover andare a ripescare dal database medesimo i dati ogni volta che serve.

È un’idea sensata, ovviamente, ma credo che abbia un uso più limitato di quanto si pensi, soprattutto in tempi come questi fatti di architetture distribuite, dove la cache può diventare un’arma a doppio taglio.

Ad esempio, quando seguivo con più attenzione la mailing list di WebObjects c’era spesso una domanda ricorrente “Ho n istanze della stessa applicazione, collegate allo stesso database; come faccio a ‘far vedere’ le modifiche dell’istanza A all’istanza B?”

Per risolvere questo problema nel tempo sono state sviluppate diverse soluzioni, l’ultima di cui sono a conoscenza è composta da er.extensions.remoteSynchronizer e er.jgroups (che usa, appunto, JGroups).

La comples­sità aumenta considerevolmente e abbiamo comunque risolto solo una parte del problema, visto che se un processo aggiorna il database al di fuori del contesto delle applicazioni A e B le loro cache risultano comunque invalidate.

Inoltre, il problema potrebbe essere considerato risolto solo se ci limitiamo a sistemi tradizionali client/server, ma su web cambia tutto: è un’architettura fondamentalmente stateless, dove le cache intermedie non vanno molto d’accordo con questa caratteristica (un’altra manifestazione dell’end-to-end argument).

Se aggiungiamo questo para­metro al calcolo dei costi/benefici ci accorgiamo che il vantaggio del caching risulta molto più ambiguo.

Qualche anno fa, Charles Petzold si è domandato se l’uso di Visual Studio possa rimbambirci:

Life without Visual Studio is unimaginable, and yet, no less than PowerPoint, Visual Studio causes us to do our jobs in various pre­defined ways, and I, for one, would be much happier if Visual Studio did much less than what it does. Certain features in Visual Studio are supposed to make us more productive, and yet for me, they seem to denigrate and degrade the programming experience. #

Cito questo paper per suggerire che gli strumenti che usiamo pos­sono avere veri e propri effetti collaterali. Bene, ma che c’entra con gli ORM?

C’entra in questo senso: se gli strumenti che uso non mi consentono di avere una visione d’insieme di tutti gli aspetti dell’applicazione, ho più difficoltà a ricostruire mentalmente questa visione. Più il progetto è complesso e più questo problema diventa sensibile. Se potessi usare un solo linguaggio la situazione sarebbe semplificata e gestibile completamente all’interno di un IDE.

Ecco quindi che suona come una buona idea quella di evitare l’uso dell’SQL attraverso una mappatura verso un qualche linguaggio a oggetti. È in fondo la stessa idea diGWT, applicata questa volta a JavaScript.

Ovviamente gli IDE si sono evoluti e quindi pos­sono gestire molto meglio di prima più linguaggi in modo integrato, ma quando è nato l’EOF tutto questo era ancora di là da venire: dove oggi si usa solo Eclipse una volta c’erano il Project Builder, il WebObjects Builder, l’EOModeler (e poi succes­sivamente anche il Rule Editor). Ma, appunto, era un limite degli strumenti, non una neces­sità intrinseca per poter programmare produttivamente con i database.

Vorrei innanzitutto ringraziare per i commenti al post: mi hanno dato del materiale su cui riflettere. Avrei voluto rias­sumerli e integrarli con le mie osservazioni, ma sarebbe stato un post troppo lungo.

Sintetizzerei la questione in questi termini: non tutto è misurabile, di conseguenza, non tutto è dimostrabile con qualche esperimento e credo che il caso di Bowman ne dia un esempio.

Con una battuta, se qualcosa non è quantificabile è inutile accanirsi nel volerlo misurare. Ovviamente, quello che ieri era qualitativo domani potrebbe essere quantitativo e allora riusciremo ad applicare i metodi adatti. La linea di confine si sposta in continuazione.

Chiudo ringraziando Matteo Balocco per aver segnalato la pre­sentazione di Nicole Sullivan. L’avevo vista a dicembre e mi sono ripromesso di prendere qualche appunto appena pos­sibile perché contiene diversi spunti. La scorsa settimana ho visto anche Professional frontend engineering. Consigliato.

Una obiezione che viene subito in mente contro l’idea di ridurre i domain objects a semplici EOGenericRecord è quello dell’antipattern (o code smell, fate voi) del cosidetto Anemic Domain Model:

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have.

The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

Sembra una descrizione esatta di quello a cui porta il mio approccio. Ci sono però delle ulteriori considerazioni da fare.

Prima di tutto, l’EOGenericRecord non è proprio una semplice Data Class e fornisce già un bel po’ di logica pronta all’uso e se non basta c’è la versione pompata di Wonder. Di conseguenza il mio approccio sembra più a quello che viene definito un Service Layer:

Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expres­sive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or neces­sary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

In secondo luogo non mi sembra che le argomentazioni di Fowler siano molto convincenti. È vero che l’accoppiamento fra dati e procedure è la ragion d’essere dell’OOP ma questo non dimostra che sia sempre l’approccio migliore (cosa che anche Fowler riconosce). Inoltre non viene portato un singolo esempio concreto di una situazione in cui un Domani Model è chiaramente superiore, a parte gli esempi ovvi.

Distinguere chiaramente i pro e i contro è difficile anche perché i criteri di valutazione sono in parte teorici e in parte pratici (almeno nel mio caso). Ci torneremo.

Doug Bowman è un designer che ha lasciato Google qualche tempo fa ed è stato commentato diffusamente nei blog per via delle motivazioni che ha dato e di cui cito il pas­saggio per me più significativo:

Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle. #

Molti dei commenti si sono concentrati sul supposto contrasto fra i designer e gli ingegneri, essendo i primi più — diciamo così — istintivi e i secondi interes­sati solo ai dati crudi.

Credo sia un punto di vista sbagliato. Prima di tutto, il design non è arte applicata né dare semplicemente un aspetto piacevole alle cose. L’aspetto estetico è sempre legato all’obiettivo del progetto (o almeno dovrebbe esserlo).

Questa linea di ragionamento sembra però portare dritti dritti al testare 41 diverse gradazioni di blu ed è proprio qui il punto: non mi sembra un approccio molto da “ingegnere”. Non sono proprio gli ingegneri ad essere considerati pragmatici e attenti al rapporto costi/benefici?

Questa serie di post sta diventando una saga… Come spesso capita, una volta che si inizia a dubitare, le domande fioccano. 

Di solito, una volta mappata la tabella sulla classe poi pos­siamo implementare la cosiddetta business logic in quella classe. Spesso, però, succede che questa business logic tocchi più classi contemporaneamente; quindi mi sono chiesto: non sarebbe più semplice considerare quelle classi come “pas­sive” — per così dire — e implementarla completamente al di fuori di esse? Nell’EOF, questo equivale a mappare tutte le tabelle con l’EOGenericRecord o una sua sottoclasse.

Inciso: questo è un difetto più generale dei linguaggi OO: devi sempre avere una classe o un istanza di quella classe a cui “attaccare” un metodo. So benis­simo che solitamente questa caratteristica non è vista in modo negativo ma sono arrivato a un’altra conclusione; ne parleremo un’altra volta.

Sull’altro versante, quello del database, abbiamo tutte quelle operazioni come le join e gli aggregati (SUM, AVG e così via) che sono molto più facilmente utilizzabili direttamente a quel livello. In questi casi le uniche pos­sibilità sono: aggirare la mappatura e manipolare i risultati grezzi o definire delle ulteriori mappature.

Di solito pre­ferisco usare la prima soluzione: la mappatura non sarà completa ma copre almeno i casi principali. La seconda appesantisce il domain model di entità/classi con uno scopo limitato a casi speciali.

A dispetto dei “great blunders” (1, 2), per un certo tempo ho tenuto la vocina critica opportunamente al di sotto della soglia uditiva; mi sembravano questioni marginali e comunque lavorare con l’EOF era divertente ed elegante, soprattutto rispetto a prodotti analoghi, come Hibernate.

Infatti, ho cominciato ad avere qualche dubbio serio su questioni che non riguardano direttamente la scorretta analogia classe-tabella. Semplicemente, un giorno ho cominciato a chiedermi se, al posto di mappare il nome del cliente da VARCHAR a String, non sarebbe stato meglio definire una classe ad hoc.

In fondo — mi dicevo — che senso ha scrivere una cosa del tipo cliente.nome().equals(indirizzo.via()), visto il loro significato è completamente diverso? È vero, di solito usiamo String per entrambi i valori e anche gli eventuali vincoli d’integrità potrebbero essere molto simili, ma non ha molto senso confrontare un nome con una via.

Purtroppo, per quanto l’idea sia corretta, la comples­sità del codice schizza alle stelle perché non è semplice implementare la cosiddetta “specialization by constraint”; con l’EOF, in Java, non sono riuscito a ottenere risultati decenti.

E così ho cominciato a ripensare il mio approccio.