L'accesso ai dati secondo me, ovvero basta con le troppe chiacchiere...

Sono (con orgoglio) un dipendente Microsoft, una azienda che ha fatto molto nel campo dello sviluppo software negli ultimi diciamo 20 anni, sia dal punto di vista tecnico che lato business. Tra le molte cose, ha "inventato" il titolo di MVP, alimentato le Community di sviluppatori sulla propria tecnologia con attività, fondi e risorse rendendole realtà molto potenti e influenti dal punto di vista "politico", ha introdotto nuove tecnologie o prodotti che sembravano essere la manna dal cielo per la soluzione di tutti i mali del mondo per poi fare marcia indietro qualche mese dopo, tutte cose che, come chi mi conosce sa bene, non mi hanno sempre trovato molto d'accordo. Questo per dire che non sono mai stato esattamente un "allineato" acritico al pensiero comune, e come me fortunatamente ho trovato molte altre persone in questa azienda.

La componente di accesso ai dati nello sviluppo di soluzioni complesse mi ha sempre affascinato. Me ne occupo da sempre, ho anche provato a scriverci un libro, e sono ancora più convinto della sua importanza oggi, che a livello architetturale si sta andando sempre più concretamente verso scenari ibridi legati a temi come l'orientamento ai servizi, l'erogazione di questi servizi in diverse modalità e così via.

Io sono sempre stato un "minimalista" anche nel campo dello sviluppo software, convinto e ispirato, da appassionato di corse motoristiche, della bontà della frase del compianto Enzo Ferrari che diceva che "su una macchina da corsa, tutto il superfluo è pericoloso perchè si può rompere". Ho sempre trovato che questo principio si applicasse alla perfezione al tema dell'accesso ai dati e sono da sempre stato un ferreo sostenitore della semplificazione di tutte le attività legate all'interazione con una sorgente dati da parte delle applicazioni. Nelle "ere geologiche" da me trascorse nel mondo del software ho visto ogni sorta di approcci, basati da sempre sul concetto della "bacchetta magica" convinti che "no, non ti preoccupare di scrivere correttamente l'accesso ai dati della tua applicazione, usa il mio componente XYZ e preoccupati solo della logica della tua soluzione...", dove ad XYZ si possono sostiturire ad ondate successive cose del tipo Data Environment, BDE, accrocchi vari, O/RM di 1', 2' e 3' generazione, ecc. ecc.

Ho sentito parlare di mirabolanti approcci architetturali basati su infiniti giri di paroloni su HKZW Driven Design, di indipendenza (ignorance, uh?!? proprio vero...) dalle diverse sorgenti dati, dove ovviamente nessuno ci capisce una mazza, ma per non fare la figura del somaro, con faccia mista tra interessata e corrucciata, tutti annuiscono e applaudono il guru di turno che, puntualmente, si ritrova nei casini quando sui progetti dei clienti queste cose devono essere messe in pratica...

No, non voglio cadere nella polemica ma fare riflettere su certe alcune argomentazioni che certamente hanno riempito migliaia di pagine di blog e di commenti, ma che a mio parere dovrebbero essere riportate ad una sfera architetturale che noi comuni mortali (grazie nonno per avermelo insegnato) si chiama DEL BUON SENSO!!!!

Indipendenza dalla base dati

Che cosa intendiamo realmente? L'indipendenza da uno schema relazionale ben definito? L'indipendenza dal concetto di RDBMS stesso? Da un prodotto specifico? In tutti questi casi, vale veramente la pena ricorrere a delle soluzioni (a mio parere spesso sovra-ingegnerizzate) così complesse per ottenere il risultato? Se sto sviluppando una soluzione custom ad hoc, che senso ha tutto questo? Se sto sviluppando un framework su cui altri implementeranno soluzioni per il cliente finale (tipico scenario da ISV) è veramente questa la soluzione per avere un certo grado di indipendenza dallo schema e dalla base dati da utilizzare? Vale veramente la pena?

O/RM 

Non mi sono mai piaciuti e continuano a non piacermi! Credo che generino più problemi di quanti ne risolvono e che alla fine falliscano in tutti i risultati che si prefiggono di ottenere. Lo so che Microsoft ci prova da anni (vero Luca? :), che ora è uscito LINQ2Sql (per favore, il prossimo che scrive o dice che LINQ è un O/RM ci pensi su un attimo prima di dire una stupidata..) e che sta per uscire LINQ2Entities e il relativo Entity Framework ma continuo a non essere d'accordo, tranne che per pochi, particolari, scenari applicativi. Le applicazioni che vedo tutti i giorni, a mio parere devono continuare ad essere scritte con tutta l'attenzione e le risorse necessarie a progettare uno strato di accesso ai dati ottimizzato, efficace, specializzato e così via. Il principio deve essere sempre e comunque quello del buon senso, con un oculato utilizzo delle risorse, riduzione del locking quando possibile, utilizzo di tutte le forme di ottimizzazioni disponibili nelle diverse sorgenti dati e quant'altro? Ci vuole molto tempo a scrivere una applicazione così? Beh, scusate, che cosa ci pagano per fare??

Ho passato anni a sentire sciocchezze e discussioni su come rappresentare le entità legate ai dati e come trasportarle all'interno dei vari layer di una applicazione e tra i diversi servizi. "I DataSet sono un schifezza.... quelly Typed poi sono una vera maledizione divina..." e cose simili, ed ora mi volete raccontare che una qualsiasi implementazione open source o meno di uno di questi mastodonti "ibernati" diventa un fuscello di efficenza e di ottimizzazione? Ma fatemi il piacere...

L'SQL dopo tutto non è il male assoluto, tutto sommato non ci vuole molto ad impararlo per bene ed a utilizzarlo nelle sue diverse salse. E non è che stiamo parlando di rocket science... su che è semplice :)

ADO.NET non andrà in pensione, non vi preoccupate, continuate ad utilizzarlo e scoprirete che c'è sempre tanto da imparare. LINQ utilizzatelo se vi serve nella business logic delle vostre applicazioni, come un approccio valido e interessante alla manipolazione di oggetti in memoria. LINQ2SQL, se volete,  limitatelo a scenari di prototipazione o ad aree non critiche delle vostre soluzioni, non fatelo diventare in Data Environment del 21' secolo...

LINQ2Entities, Entity Framework e Entity Data Model, seppure molto interessanti come principio, valutatene gli aspetti e le implicazioni a 360', forse non saranno sempre e comunque adatti a qualsiasi scenario.

In sintesi: mantenete il controllo!! una scelta sbagliata in questo ambito in fase di progettazione si paga cara.. molto cara!

Update: semplicemente fantastico!!