Domain Model e ORM
Ormai è consuetudine (ed auspicio) quella di scrivere codice attinente a pattern architetturali ben consolidati e opportunamente inseriti nel disegno dell’architettura del software che si sta implementando.
Uno dei pattern architetturali più “in voga” ai giorni d’oggi è il Domain Model che parte dal principio di fondo secondo il quale si vuole avere una astrazione quanto più alta possibile della parte di persistenza dei dati. Ciò al fine di poter lavorare con oggetti piuttosto che con entità vere e proprie e, soprattutto, di poter, laddove possibile, non cablare nel codice logica relativa ad un tipo di database piuttosto che ad un altro (SQL, piuttosto che Oracle, piuttosto che MySQL, etc…).
Tramite l’utilizzo di questo pattern, infatti, come si evince dallo stesso diagramma riportato sopra, si tende a rappresentare l’insieme dei dati mediante una modellazione degli stessi in oggetti, così come dettano i principi della Object Oriented. Ciò, molto a grandi linee, avviene facendo in modo di far corrispondere ad ogni dato presente nello specifico database un’istanza di classe, e ad ogni relazione tra le tabelle dello stesso, uno specifico riferimento.
Questo, ovviamente, può valere limitatamente ad applicazioni non eccessivamente complesse, dal lato della persistenza almeno, perché in basi dati con tante tabelle e tante relazioni tra di esse l’andare a scrivere le classi, e a gestire i vari riferimenti tra le stesse può risultare impresa non banale.
Questo risulta il vero principale limite dell’adozione di un pattern di questo tipo, limitazione che però viene quasi interamente superata mediante l’adozione di un ORM (Object Relational Mapping) cioè di una tecnica che fornisce un mapping tra oggetti e tebelle di un database relazionale, e che provvede a mettere a disposizione del programmatore tutta una serie di strumenti per la gestione delle operazioni fondamentali relative alla persistenza e alla manutenibilità dei dati del database ( il salvataggio, la lettura, la cancellazione etc…).
L’ORM è quindi in grado di fornire delle funzionalità ad un livello di astrazione abbastanza elevato da poter permettere allo sviluppatore di lavorare con oggetti che fisicamente mappano record di una o più tabelle diverse nel database togliendo, tra le altre cose, in tal modo, il cruccio di andare a scrivere query in join particolarmente complesse. Inoltre un buon ORM è in grado di attivare tutti i meccanismi di rollback delle transizioni, cancellazioni di record di tipo “cascade” e lettura dei dati di tipo “lazy”, cioè la possibilità di leggere dal database solo i dati che servono di un oggetto piuttosto che andare a fare query molto pesanti per tirar su tutte le informazioni relative allo stesso.
Oggi in commercio esistono tanti ORM parecchio affermati e tra tutti una nota di rilievo ha sicuramente Hibernate (o NHibernate nella versione per .NET) nato come progetto open source per Java, originariamente sviluppato da un team internazionale di programmatori volontari coordinati da Gavin King; in seguito il progetto è stato proseguito sotto l’egida di JBoss, che ne ha curato la standardizzazione rispetto alle specifiche J2EE.
Una possibile alternativa degli ultimi giorni ad Hibernate è quella introdotta dalla Microsoft col nuovo framework e con la nuova versione del Visual Studio (il 2008)e cioè LINQ. Questo è un ORM nato con lo scopo di tradurre le query integrate al linguaggio scelto (quindi query di tipo LINQ) in query SQL per l’esecuzione sulla base dati e, in seguito, di tradurre il risultato della query in strutture dati tabulari costituenti delle istanze di oggetti vere e proprie. In questo momento, però, LINQ riesce a mappare nativamente database di tipo SQL Server (LINQ to SQL) mentre risulta ancora parecchio macchinosa l’integrazione dei driver per database differenti (LINQ to Entity).
Postato in: Informatica, Pattern Architetturali | Contrassegnato da tag: Domain Model, Hibernate, LINQ, ORM, Pattern
Ciao Roberto, mi sento onorato del fatto di essere il primo ad intervenire su questo tuo Blog, spero davvero possa diventare quel punto di incontro dove la community dei professionisti IT possa confrontarsi, trovare risposte ai propri problemi, o semplcemente, rilassarsi.
Provo a commentare questo topic,che ritengo molto interessante e che sicuramente potrà essere per molti, lo spunto per approfondire l’argomentazione sugli ORM e le sue applicazioni. Purtroppo, il mio personale approcio a questa nuova filosofia di pensiero e è decisamente “contro corrente”. Mi rendo perfettamente conto che l’ambizione principale dei moderni Architect IT quella di raggiungere un livello di astrazione tale da rendere semplice ed il meno dispendioso possibile (anche in termine di tempo) la progettazione e lo sviluppo del software; ci si avvale di linguaggi “portabili” per poter con il minimo sforzo rendere le nostre applicazioni OS indipendent, e si scelgono linguaggi di programmazione che spesso abbattono ogni barriera di formalità (dichiarazione ed allocazione variabili, strutture gerarchiche, modellizzazione, ecc..). Sono fermamente convinto che questo approccio al software developing è decisamente poco pragmatico e, per quanto indubbiamente “conveniente”, la sua diffusione nel mondo informatico è stata dettata da vantaggi di natura commerciale, piuttosto che di “affidabilità” del prodotto risultante.
Mi spiego meglio:
se un cliente mi commissiona un prodotto, è sicuramente più vantaggioso realizzare il software nel minor tempo possibile, piuttosto che “perdere tempo” ad ottimizzare i costrutti, trovare il miglior algoritmo di ordinamento, la routine che mi garantisca minor tempo di accesso ai dispositivi di archivizione di massa, ecc…
Dopotutto, perchè “perdere tempo ad ottimizzare i cicli macchina delle mie routine, quando il mercato mi offre del nuovo hardware che nello stesso intervallo temporale riesce ad eseguirne un numero maggiore?”.
Avendo a disposizione più tempo, posso produrre più software per poter servire un portafloglio cliente più ampio. Fila tutto, non fa una grinza…. Quasi. Perchè, tra il miei 2000 possibili clienti, un giorno ce ne sarà uno che mi chiederà di realizzare un software che non richieda l’aggiornamento del suo parco macchine (server), e che garantisca un servizio a un esercizio di 10000 utenti. E adesso? Io sono abituato a sviluppare software portabilissimo, interpretato da uno strato logico che traduce portabilmente ad una macchina virtuale che passa le sue chiamate ad un framework si interfaccia con il layer applicativo del Sistema operativo che poi le passa al kernel dello stesso che le traduce in linguaggio macchina che poi la processore è eseguito a livello di microistruzioni. Anf, anf… che fatica!!!
Quindi:
O investo in “RICERCA” (certo, dopo 10 anni che sviluppo in Visual Automatic Intelligent Studio 104.7 SP19, che vuoi che ne sappia di C++??), dicendo al mio cliente che occorrono 74 anni per dare luce al suo prodotto,
Oppure
Per non perdere la faccia (aka nessun altro cliente verrà da me a chiedere di sviluppare software), gli finanzio l’aggiornamento del sopracitato “parco macchine” (il nuovo Intel Deca-Core con 55 pipeline riesce ad eseguire il mio visuale, portabilissimo, accattivamnte, programma “Hello World” in soli 3 secondi!),
Oppure
Perdo la faccia e decido di studiare da idraulico come voleva mia mamma (chissà perchè..).
Ok.. dopo questa buffa parentesi, ritorno ad esprimere le mie perplessità sul topic (sempre io contro il mondo intero); la nuova estensione del Framework .NET si pone come “strato” aggiuntivo tra l’applicazione e l’accesso ai dati. Quello che mi domando è: perchè si cerca di creare un nuovo standard di accesso ai dati, layer indipendent, quando esiste già uno standard, che comunque dovrà essere usato come sub strato del nostro nuovo layer? Mi riferisco a SQL, definito anni fa, con gli stessi intenti: avere a disposizione un unico linguaggio per poter interagire con i dati, siano essi archiviati in un file sequenziale, che in un file XML, che in un DMBS Oracle, DB2 o SQL Server. C’è da dire che “Chi” (e non farò il nome) propone l’innovazione, non ha mai voluto consolidare il proprio/i software e strumenti di sviluppo a questo vecchio standard, piuttosto ha sempre cercato di affermarne uno proprio (proprietario) contando sulla propria posizione di egemonia nel mercato.
Basti pensare che LINQ sarà sicuramente più performante (naturalmente è una ipotesi, non un’illazione) se usato in un contesto in cui tutta infrastruttura gioca “in casa” (la “mamma” di LINQ lo avrà certamente educato a “non litigare ” con i suoi “fratelli”),mentre magari un DBMS di terze parti dovrà essere “accollarsi” lo strato “LINQ” a beneficio della compatibiltà ma a scapito delle proprie prestazioni.
Purtroppo le tendenze di mercato ci impongono scelte a volte drammatiche.. spero solo che questo mio “sfogo” contribuisca a renderle quantomeno consapevoli.
Mi fa piacere lo “sfogo” di Gianni, ovviamente non mi trova concorde ma da’ maggior forza al mio discorso iniziale fondato sul vero discriminante dell’informatica io”commerciale” e “pratica” ovverosia il “TRADE OFF”.
Probabilmente ha ragione quando scrive che se la commessa riguarda un software che deve durare 1 mese (o poco più), e ci sono pochi soldi nel piatto, la scelta andrà verso il: “prima mi sbrigo meglio è…” ma se già la stessa situazione fosse proposta con un’ottica futura di manutenibilità del prodotto allora lì le cose sarebbero parecchio diverse.
Ormai sempre più spesso i progetti che vengono sviluppati per conto terzi o per conto proprio sono nella maggior parte dei casi dei progetti che abbracciano un’ampia sfera di problematiche contemporaneamente: un’applicazione oggi è normale che nasca per essere utilizzata sia stand alone sia tramite web, che si integri con una base dati e che abbia la gestione di scambio documenti in XML… quindi scenari come quello evidenziato nel post di risposta, mi sembrano, nella pratica, difficili da incontrare, fermo restando, e ne abbiamo avuto sopra la riprova, che continuano ad esistere in determinati settori produttivi.
Inoltre una riflessione volevo farla su una frase in particolare che mi ha colpito; quella, nello specifico, relativa al tempo da dover investire in “Ricerca”…
Per la mia esperienza, infatti, posso affermare che molte volte l’approccio alle varie problematiche di cui si sente disquisire sul web, o nelle community in generale, è più complicato “a dirsi che a farsi”; nel senso che occorre un po’ di tempo a disposizione e parecchia volontà di imparare cose nuove, dopo di chè con una buona preparazione sulle spalle, e un po di fatica nel digerire certi argomenti e nel metter su qualche programmino di prova, il risultato si riesce ad ottenere piuttosto agevolmente e soprattutto si arricchisce il proprio bagaglio culturale approcciandosi a nuovi mondi e nuove metodologie diversamente sconosciute.