<< Scrum: un processo di sviluppo Empirico 3 (generative rules) | Home | Colors of the autumn leafs dance >>

Il ciclo di vita delle tecnologie di accesso ai dati




Osservando applicazioni software di successo in aziende di successo (longeve) mi è capitato di vedere base di dati con 30 anni di vita ancora arzille e vitali e applicazioni software con 10 anni di vita ancora sviluppate e in uso.


Guardando alle code-base di vari team, una cosa che talvolta mi salta all'occhio è la presenza contemporanea nella stessa applicazione di più tecnologie di accesso ai dati incompatibili tra loro (non possono condividere connessione, transazione, lock, recordset/DTO/mapping, query).


Questo mi ha fatto riflettere sul ciclo di vita delle tecnologie di accesso ai dati Microsoft (alcune a basso e alto livello sono: ODBC, OLE DB, .NET Data Provider, RDO, ADO, ADO.NET, Data Set, Linq2Sql, Entity Framework; su wikipedia ci sono più dettagli  qui e qui) che ogni 2-3 anni vengono virtualmente "obsoletate" in favore di una nuova diversa e incompatibile tecnologia.


Ho raccolto i dati di longevità di altre tecnologie sviluppate con una strategia consistente incrementale e evolutiva per confrontarle con le tecnologie di accesso ai dati Microsoft  :
  • Microsoft COM: in evoluzione da circa 20 anni
  • Microsoft WinForms: in uso corrente e ha circa 10 anni
  • Microsoft SqlServer: quello che conosciamo oggi ha almeno 10 anni
  • Hibernate: circa 8 anni
  • NHibernate: circa 4 anni



Le tecnologie MS di accesso ai dati vengono sviluppate di piú  secondo una strategia consistente incrementale e evolutiva  o di piú secondo una strategia a breve termine e con frequenti stravolgimenti ? Qual'è la tua opinione e come gestisci la cosa ?

Print | posted @ mercoledì 20 gennaio 2010 20.04

Comments on this entry:

Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by bozz at 21/01/2010 8.35
Secondo me seguono una strategia a breve termine. Non si spiegano altrimenti i repentini cambi di direzione nella politica per l'accesso ai dati.
Mi ricordo che la tecnologia oledb aveva come scopo la definizione di un'unica interfaccia comune per l'accesso ai dati (scriviamo il codice una volta solo e rendiamolo compatibile con vari dbms).Poi sono arrivati i .net provider, uno per ogni specifico database (per cercare le prestazioni).
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by FedeSpagno at 21/01/2010 10.04
Il problema é secondo me più generale di tutte le code-base che vivono per anni (> 3) e non solo per quanto riguarda l'accesso alle basi di dati. Pensiamo a vari progetti OSS che nascono, vivono qualche anno nell'entusiasmo, vengono adottatti in maniera estensiva e poi muoiono perchè soppiantati da altri tool / framework più potenti (o magari semplicemente più di moda); nei nostri code-base rimangono e ci troviamo a doverci convivere, senza possibilità di aggiornamento, e con prospettive di alti costi di sostituzione.
Per quanto riguarda l'accesso ai dati il vero problema é che dobbiamo preoccuparcene: siamo costretti ad entrare nel merito perchè esiste la necessità di fare convivere 2 mondi completamente diversi, quindi scendiamo a compromessi per poterli fare convivere. Se pensiamo a Nibernate/Nhibernate (o EF) l'idea é proprio quella rendere più trasparente la loro coesistenza, ma ancora dobbiamo preoccuparcene, ed é quindi ragionevole che il futuro ci riservi ancora novità, incompatibili e che avranno vita breve.

Potremo pensare di superare il problema solo quando i due mondi, ora distinti e separati, convergeranno verso un unico modello dove la persistenza é insita nel framework, o nel linguaggio, in maniera completamente trasparente senza bisogno di intermediari che ci aiutino a collegare due mondi diversi.

Tornando alle tue domande, la gestione di questi aspetti é veramente un dramma che si porta dietro costi altissimi; porto una mia piccola esperienza: abbiamo impiegato anni a rendere stabile e utile ai nostri scopi una piccola libreria basata su dblib di sql server, ora non é più supportata e negli anni sono state sviluppate varie altre librerie basate ad esempio su Odbc, ma nessuna di queste offre le funzionalità che ha quella originale e ora ci troviamo a dover sostenere costi altissimi di sostituzione difficilissimi da mettere a budget per ragioni penso evidenti.












  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Luca Minudel at 21/01/2010 23.11
mi vengono in mente 2 cose che possono aiutare a mitigare questi problemi riportati
1-non far uscire i dettagli della tecnologia di accesso usata fuori dal data-layer: gui e dominio nondevono conoscerla
2-nessun dev del team puo usare una seconda tecnologia di accesso ai dati, puo solo sostituirla completamente con un'altra
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by FedeSpagno at 22/01/2010 13.03
Correttissimo, il mio esempio é però relativo a code-base con più di 10 anni con diversi data layer che come giustamente fai notare sono basati su diverse librerie che risultano sempre più incompatibili. Il mio esempio serviva a rafforzare le tue argomentazioni, e le mie rispetto all'esigenza di nuovi paradigmi che ci permettano di superare il problema, altrimenti saremo sempre costretti ad inseguire, nuove idee valide ma che non affrontano il problema alla radice (a questo proposito segnalo blog.wekeroad.com/.../thoughts-on-ef-vs-nhibern...)
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Luca Minudel at 22/01/2010 20.28
concordo, una opzione che va aggiunta nel ventaglio dei possibili approcci.

subire questa varietá senza fare niente e e spendere tutto il proprio technological complexity budget per l'accesso ai dati non sembra saggio
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Giovanni D'Arienzo at 26/01/2010 23.45
Vogliamo parlare anche di azure e le flat table , non esiste nemmeno piu il concetto di relazionale.
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Stefano at 15/02/2010 21.46
Uhmm... secondo me seguono una strategia a lungo termine, che come molte volte succede in questi casi si rivela alla lunga sbagliata, ma non cosi' spesso in Microsoft, dove sembra alla fine con una botta al cerchio ed una alla botte riescono quasi sempre ad avere ragione.
Ad esempio, COM, a mio avviso purtroppo, e' ancora presentissimo e base di tutto quello che e' targato MS, dagli OS ai programmi server. Lo stesso Visual Studio ne e' pienissimo ed e' la maggiore causa del lento passaggio da 32 a 64 bit delle applicazioni.
Anche nell'accesso a SQL Server usando il SQL Native Client di .Net sotto sotto si usano degli oggetti COM.
Per il resto io non vedo tutto questo stravolgimento, al contrario.
Vedo tante evoluzioni, magari alle volte radicali (come .Net), ma la big picture resta abbastanza uniforme.
Anche Entity Fx non e' altro che una evoluzione di Ado.Net (con metodi come GetSchema si poteva creare il proprio ORM piu' o meno rudimentale gia' dalla 2.0) e Linq estende, anche pesantemente, il concetto di interfacce come IEnumerable gia' presente dalla 2.0.
Quindi io vedo maggiormente una grande evoluzione, alle volte di un disegno veramente molto ben fatto e valido (come per il .Net Fx), altre di un disegno sicuramenter molto valido, ma magari un po' datato (come COM).
Una visione che cercava di essere lungimirante ma che si e' rivelata decisamente sbagliata e che e' stato oggetto di repentini cambi di direzione e stravolgimenti di fronte a mio avviso e' quella tecnologia chiamata EJB come tutta la galassia di mondi cosi' diversi che i piu' etichettano come "semplicemente" Java.

Ciao, Stefano.

PS: SQL Azure ha alla sua base sempre e solo SQL Server dimostrando l'ennesima evoluzione ed estrema astrazione dello stesso concetto di base praticamente rimasto immutato da circa 10 anni. ;)
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Luca Minudel at 15/02/2010 23.27
Ciao Stefano

> Anche Entity Fx non e' altro che una evoluzione di Ado.Net (con metodi come GetSchema si poteva creare il proprio ORM piu' o meno rudimentale gia' dalla 2.0) e Linq estende, anche pesantemente

La riflessione riguarda la interoperabilitá in uso: non possono condividere la medesima connessione o partecipare alla stessa transazione.
Per fare un paragone gli oggetti COM realizzati con diverse versioni di COM o Winform realizzati con .NET 1.0 o 2.0 possono interagrarsi tra loro sonza problemi ne grosse limitazioni.

  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Stefano at 16/02/2010 11.29
Ciao Luca,
non ho ben capito la tua ultima affermazione.
Cosa intendi per "non possono condividere la stessa connessione"?
Sul fatto della iterazione senza problemi tra oggetti COM di diverse versioni di Windows avrei qualche dubbio. ;)
  
Gravatar # re: Il ciclo di vita delle tecnologie di accesso ai dati
by Luca Minudel at 19/02/2010 15.37
Intendo che quando hai codice di accesso ai dati sullo verso lo stesso db e le stesse tabelle, una scritta con ADO.NET verso SqlServer con transazioni COM+ e una con LinQ2Sql, queste non possono usare partecipare alla medesima transazione.

Non ho invece avuto mai poblemi usando dalla stessa applicazione oggetti COM distinti e di generazioni geologiche diverse. Hai un esempio che mi aiuti a capire ?
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 7 and 5 and type the answer here: