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 ?

Tags : Progettazione Software |

Print | posted @ mercoledì 20 gennaio 2010 22:04

Comments on this entry:

# re: Il ciclo di vita delle tecnologie di accesso ai dati

by bozz at 21/01/2010 10: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).

# re: Il ciclo di vita delle tecnologie di accesso ai dati

by Giovanni D'Arienzo at 27/01/2010 01:45

Vogliamo parlare anche di azure e le flat table , non esiste nemmeno piu il concetto di relazionale.

# re: Il ciclo di vita delle tecnologie di accesso ai dati

by Stefano at 15/02/2010 23: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. ;)