venerdì 29 maggio 2009

Piccoli Problemi Architetturali

Qualche tempo fa, Dino Esposito esprimeva con diplomazia invidiabile un concetto:
Ora che MS sembra curarsi un po' piu' del design del codice che gli sviluppatori VS andranno a scrivere si nota un livello di cultura del design non del tutto atteso. Come avrebbe detto la mia professoressa di italiano/storia/geografia alle medie, al ragazzo (MS) mancano un po' le basi. Ma ha volontà di imparare e magari ce la farà. Sia pure a suon di strafalcioni.
Dino Esposito, 06/04/2009
Ieri sera ho partecipato alla prima conference targata Microsoft della mia vita.

Bella gita, bel hotel e bella gente. Ottimo marketing, poca chiarezza.

Non conosco il mondo .NET che da qualche mese per cui merita il beneficio del dubbio.
Tuttavia devo ammettere che le formae mentium che ho rilevato alla conference non mi fanno ben sperare.

Roberto Messora ha esposto e confrontato con grande chiarezza e competenza NHibernate e Entity Framework e devo dire che è stato utilissimo ascoltarlo sotto un punto di vista tecnico.


Durante la conferenza, sono stati abbozzati dei criteri di scelta fra i due secondo quella che Roberto ha definito una "prospettiva aziendale", orientata alla "produttività" piuttosto che al "formalismo architetturale".


In estrema sintesi, EF 4.0 sarà più produttivo di NHibernate perché richiederà meno apprendimento (grazie sostanzialmente alla integrazione in Visual Studio 2010 e al designer grafico).
Buono a sapersi. Ottimo per i progetti data driven e quick & dirty.

Sempre in estrema sintesi, NHibernate permette approcci migliori architetturalmente consentendo di scrivere codice più testabile e più flessibile al cambiamento.
Il prezzo da pagare consiste sostanzialmente in una curva di apprendimento più ripida dovuta all'assenza di tool che ne semplificano l'adozione.

A tal proposito avete mai provato l'ultima fatica del Fatica Lab?
Fornisce un DSL per lo sviluppo di applicazioni basate su NHibernate secondo un approccio domain first.


Personalmente comunque preferisco disegnare l'architettura e scrivere il codice, per cui penso che opterò per NHibernate a meno che il progetto in questione non abbia margini così ristretti o esigenze così banali da non permettere o non richiedere una fase di analisi seria.

Entity Framework andrà benissimo se NON mi dovrò occupare in prima persona della manutenzione e dell'evoluzione del software prodotto (oppure se so che verrò pagato profumatamente per tale manutenzione / evoluzione)


Messora ha anche elencato una serie di "piccoli" problemi architetturali di cui Entity Framework soffrirebbe.

Piccoli. Piccoli. Piccoli problemi architetturali.

In generale tali problemi sono correlati all'utilizzo delle entità idratate via EF come Domain Model.
Questo ha allertato i miei sensi di "GNU".
Fortunatamente questo, dicono, è un problema "piccolo".

Andrea Saltarello, presente alla conference, ha fatto notare che il problema esiste (ed io aggiungerei è grave) a seconda della definizione di entità che si sceglie:
  • secondo il modello di Chen (definito nel 1976 ed ampiamente utilizzato nei database relazionali negli ultimi trent'anni) le entità sono sostanzialmente dati relazionati.
  • secondo il modello di Evans (o più precisamente secondo il paradigma di programmazione ad oggetti) le entità sono astrazioni cui compete gestire il proprio stato, le relazioni con altre entità (knowledge) e le operazioni relative (operation).
Ciò che mi preoccupa di più è quanto ha detto Saltarello in proposito (cito a memoria):
Alla Microsoft non interessa minimamente supportare il modello di Evans, ma fornire un sistema di incapsulamento dei dati che sia possibile far transitare facilmente fra i tiers di servizi di cui una applicazione si compone.
Per cui EF si basa concettualmente sul modello di Chen.
Le novità introdotte con Entity Framework 4.0 sono semplicemente una concessione fatta agli utenti abituati ad utilizzare NHibernate.
Infine ha aggiunto (sempre a memoria):
Questa è la vision di lungo periodo del vendor. E' necessario saperlo perché divergere dal proprio vendor è ovviamente pericoloso.
Anzitutto, visto che il vendor vende e io pago, mi aspetterei che fosse lui a seguire le mie esigenze non io le sue proposte. Anche perché fortunatamente la tecnologia avanza in modo inesorabile, ma se la si adotta "alla cieca" (o in funzione delle promesse di felicità che fa chi la vende) si rischia di introdurre molti più problemi di quanti se ne risolve.

E poi, questo vendor cambia vision abbastanza di frequente (Linq to Sql docet).

Qualora il vendor non fosse interessato alle mie esigenze, perché non cambiare vendor?
Microsoft è interessata alle esigenze di chi deve risolvere problemi complessi in domini definiti da regole di business variabili e pur ambisce a produrre prodotti software enterprise?
Se no, se è interessata solo a sviluppatori di progetti di medio periodo (che peraltro hanno assoluta dignità e fanno girare benissimo l'economia del software... fin quando qualcuno li paga) bene. Basta dirlo!
Esistono altri vendor, anche per .NET.

Se invece è interessata alla fetta di mercato software cui appartengo, dovrebbe prendere maggiormente in considerazione il modello di Evans e la programmazione ad oggetti.

Ora qualcuno penserà che io sia un talebano dell'architettura. :-D

Non è così.

Il punto è che quando adotto un paradigma di sviluppo lo faccio con cognizione di causa avendo valutato le alternative.

Se programmo ad oggetti è perché necessito della flessibilità che questo paradigma offre.

Se devo solo gestire dei dati con operazioni CRUD effettivamente il modello di Chen è assolutamente sufficiente, ma è anche sufficiente un approccio funzionale (non a caso SQL è un linguaggio funzionale). Non ho bisogno di programmare ad oggetti per scrivere un CMS insomma.
Servizi REST, AJAX, XSLT e magari qualche buon vecchio FastCGI sono probabilmente la migliore soluzione possibile in termini di efficienza e scalabilità: l'utente vedra pagine web veloci e sberluccicanti, modificherà efficentemente i contenuti di propria competenza ed il nostro cliente potrà scalare in modo semplice ed estremamente rapido.

Peraltro, con gli strumenti (culturali e tecnologici) adatti, tale approccio non richiederebbe più ore uomo che lo sviluppo di un'applicazione multi-tier enterprise in .NET o Java.

Tuttavia, se la knowledge base non lo permette, esistono moltissime soluzioni alternative che non richiedono un Domain Model perché non contemplano la programmazione ad oggetti.
Alcune non contemplano la programmazione in generale, perché di CMS belli e pronti con un sacco di splendidi temi è pieno il mondo.

Architetturalmente un sistema .NET basato su entità di EF e su servizi che le manipolano, non è molto diverso da uno bastato su struct e funzioni e scritto in Plain Old C. Qualcuno lo definirebbe addirittura un anti-pattern.
Io adoro il C, lo considero un potentissimo linguaggio multiparadigma, ma non so se svilupperei applicazioni enterprise in modo procedurale.


Personalmente scelgo .NET quando l'elenco degli ambienti che devo supportare comprende Microsoft Windows.
E scelgo C# perche mi consente di programmare ad oggetti.

Mi serve programmare ad oggetti perché il mio cliente ha esigenze più complesse che gestire dei contenuti: ha bisogno di gestire in maniera ottima un business complesso le cui regole variano nel tempo.

E mi serve perché conto su economie di scala e vorrei rivendere il mio prodotto software ad altri clienti operanti nello stesso ambito.
Da un cliente all'altro vorrei riutilizzare più codice possibile, quindi investirò il tempo necessario nell'analisi di un Domain Model appropriato per il business in questione.
Perché serve a questo cliente ma servirà anche al prossimo e a quello dopo.


La persistenza di questo Domain Model la delegherò probabilmente ad un Data Access Layer (NHibernate probabilmente, ma perché non DbLinq che copiando Linq to Sql è molto più un DAL che un ORM), ma non confondo MAI il modello di dominio con il layer di persistenza.


Il punto comunque è questo: la prospettiva aziendale deve guidare le scelte strategiche non quelle tattiche.

Un'azienda di consulenza può puntare strategicamente ad incrementare al massimo la produttività istantanea (e ridurre il costo) degli sviluppatori che impiega, riducendo al minimo i requisiti culturali necessari ad iniziare l'implementazione di un singolo progetto, che in termini economici costituiscono un costo fisso.
Minori costi fissi implicano minori costi iniziali che permettono di vincere le gare attraverso un marketing basato sul prezzo.
In questa prospettiva Entity Framework può essere una scelta ottimale per l'azienda.

La scarsa manutenibilità che potrebbe derivarne si rivelerebbe addirittura vantaggiosa, qualora il cliente fosse disposto (o costretto) a pagare per ogni singola modifica.


Un'azienda che produce e vende prodotti software invece non può permettersi di aggirare ogni volta i "piccoli problemi architetturali" che Entity Framework comporta, per cui le si impone una scelta strategicamente diversa: investire sul proprio personale e su un'architettura solida.

E' ovvio che questo comporta qualche minuto di analisi per comprendere se al prodotto in sviluppo basta un ORM o serve un Domain Model serio (nel qual caso i tempi di analisi cresceranno certamente, ma a vantaggio dei tempi di sviluppo e manutenzione).

In qualunque caso qualche giorno di studio per sfruttare un layer di persistenza già fatto fornito da un buon ORM con anni di esperienza (aka NHibernate) è certamente ben speso da qualunque azienda che punti seriamente sulla qualità del prodotto e sulla customer satisfaction permettendo fra l'altro di incrementare notevolmente la produttività di lungo periodo: se i miei prodotti sono stabili e veloci da manutenere posso implementarne di nuovi immetterli sul mercato senza costringere ottimi programmatori a fossilizzarsi per anni su progetti specifici solo perché sono gli unici a sapere come metterci le mani.


La prospettiva aziendale è una questione strategica appunto.
Come la scelta dei fornitori. Microsoft, Sun, Oracle, Red Hat... sono fornitori da scegliere.

La scelta dipende da quanto le loro proposte si adattano alla nostra prospettiva. Mai viceversa.

1 commento:

  1. ineccepibile.
    bè dai, mi fa piacere che l'intento della sessione almeno da un partecipante sia stato colto in pieno.
    :-)

    saluti
    Roberto Messora

    RispondiElimina