Ieri mi sono dedicato allo studio di un argomento che mi
ha sempre appassionato: il Data Access Layer.
Amato o odiato che sia, rappresenta nella maggior parte dei progetti software
il cuore della nostra applicazione, ed è inoltre una delle attività più
"time-consuming". Che cosa impiegare allora, per migliorare la nostra
produttività riducendo la possibilità di errori e, allo stesso tempo, favorendo
una espansione e/o modifica futura del nostro strato di accesso ai dati? Bene o
male abbiamo 4 possibilità:
- Scrivere tutto "a mano": con a mano intendo scriverci
tutte le query e tutto l'accesso ai dati impiegando Datase, datareaders e
quant'altro. La soluzione è certamente fattibile ma sicuramente non agevole nè
breve. Inoltre utilizzando un approccio "query-like" perdiamo la possibilità
di utilizzare degli oggetti di business, a meno di non crearci anche questi,
con un aumento uteriore di tempo per la realizzazione della nostra
applicazione.
- Utilizzare Enterprise Library: la nuova release di
Enterprise Library per il .net Framework 2.0 è stata molto semplificata ed è
sicuramente un buon punto di partenza per creare uno strato di accesso ai dati
robusto ed affidabile; consideriamo, infatti, che in questo caso gran parte
dei metodi per l'accesso ai dati sono già pronti e si basano su pattern
robusti e ben conosciuti. Anche in questo caso, però, l'approccio che si
utilizzerà è molto "database oriented" e poco "object-oriented", per cui in
alcuni casi potrebbe non essere una buona soluzione.
- Utilizzare un ORM (Object Relational Mapper): il mercato
offre degli ottimi ORM, gratuiti o a pagamento, che possono essere
impiegati per implementare un accesso ai dati object oriented. Mi vengono in
mente Genome oppure ORM.net o ancora NHibernate. In questo
caso perdiamo il controllo della specifica query, ma otteniamo un accesso ai
dati più coerente ed uniforme. Può piacere o meno, ma una cosa è certa:
impiegare un ORM velocizza lo sviluppo.
- Impiegare i Dataset Tipizzati di Visual Studio 2005: una
parola per definirli? Belli! Onestamente nella prima versione del Framework li
ho sempre "snobbati" in quanto estremamente pesanti e difficili da modificare;
non è possibile "imbroccare" tutto il design delle tabelle del DB al primo
colpo e farsi generare lo strato di accesso ai dati!! Con la nuova versione
sono stati introdotte così tante features da farmi rivedere in toto il mio
atteggiamento verso i Dataset Tipizzati, infatti:
- Sono query-oriented
- Sono object-oriented
- Hanno un editor interno a VS2005 che ci permette di restare all'interno
dello stesso ambiente di sviluppo per aggiungere tabelle, stored procedures
o sistemare i nostri dataset.
- I dataset possono attraversare i layer e possono essere quindi condivisi
tra tier (lo so, non è SOA puro, ma alla fine della fiera...è il risultato
che conta
)
- Si possono impiegare comandi SQL oppure Stored Procedures.
- Facilitano l'accesso ai dati e permettono di estendere le funzionalità
dei TableAdapters impiegando delle classi Partial
A proposito di questo ultimo argomento, ovvero i dataset tipizzati, consiglio
a tutti il tutorial scritto da Scott.
Happy programming!
powered by IMHO 1.3