Ultimamente sono diventato un fan degli Object Relational Mappers, in particolare di ORMapper di Paul Wilson e di NHibernate.
All'inizio ero scettico, titubante per paura di aggiungere complessità alle mie applicazioni (avete presente la Enterprise Library?); poi ho dato un consiglio "spassionato" ad un collega che mi ha trascinato con il suo entusiasmo.
Clemens Vasters, "Community Relations Program Manager for the Windows Communication Foundation at Microsoft Corporation", ritorna sull'argomento riportanto anche buoni argomenti. I soliti di chi non scrive codice ;-) e quindi non ne ha capito i vantaggi.
Proper data management is the key to great architecture. Ignoring this and abstracting data access and data management away just to have a convenient programming model is … problematic.
[...]
Many of the proponents of O/R mapping that I run into (and that is a generalization and I am not trying to offend anyone – just an observation) are folks who don't know SQL and RDBMS technology in any reasonable depth and/or often have no interest in doing so.
Sono felicissimo di non scrivere più codice SQL, confonderlo con il codice dell'applicazione (senza arrivare a scrivere la logica nelle store procedures, che avete capito?), cambiare continuamente focus da uno strumento all'altro, da un linguaggio all'altro. E' anche più facile da trasmettere al team l'accesso ai dati: non devono più occuparsene.
I puristi come Clemens hanno ragione nel dire che si rischia di dimenticare il database (valore principale e forse scopo dell'applicazione) ma chi usa un O/R Mapper sa qual'è la fatica e la mole di codice da scrivere ogni volta per l'accesso al database.
Another argument I keep hearing is that O/R mapping yields a significant productivity boost. However, if that were the case and if using O/R mapping would shorten the average development cost in a departmental development project by – say – a quarter or more, O/R mapping would likely have taken over the world by now.
Sono diventato molto più produttivo. Ora ho solo collection con cui fare databinding, non converto più da un tipo all'altro e mi son scordato dei Datasets.
Certo ho impiegato un po' di tempo per il setup dell'ambiente (configurazione e data mapping): ma alla lunga ne ho risparmiato di tempo e codice. Provate a contare le righe del vostro codice dedicate al binding con i vostri oggetti di business.. Ora li ho eliminati!
Una volta c'era l'OleDb con cui si poteva ragionevolmente adattare la propria applicazione ad un database diverso da quello per cui era stata sviluppata, a scapito delle prestazioni: forse per questo son nati i provider nativi. (ok, nel tempo anche l'Enterprise Library ha implementato un factory pattern per lo scopo).
Con il Wilson ORMapper ho cambiato al volo il database e la mia applicazione non ha fatto una piega (per la cronaca, da sql server a db2): non è certo la normalità, ma a volte risulta utile.
Prestazioni? Paul Wilson ha dimostrato in passato che per molte operazioni surclassa il caricamento di un Dataset e personalmente non ho mai dovuto ottimizzare l'accesso ai dati.
Solo per condividere le mie esperienze, non devo vendervi nulla! :-P
Se avete scritto un Data Access Layer che funziona benissimo, buon per voi! Ma guardatevi un O/R Mapper, magari open source. Sarà un'occasione per migliorare il vostro DAL o migliorare il vostro metodo di lavoro.